Un thème WordPress hérité, écrit avant l’arrivée des blocs Panier et Paiement de WooCommerce, accumule souvent des sélecteurs génériques comme .woocommerce ul.cart li ou #content table, avec une spécificité déjà élevée. Le jour où ces blocs remplacent les anciens shortcodes, ces règles continuent de s’appliquer, en plus du CSS natif des blocs, et le rendu devient imprévisible sans qu’aucune ligne n’ait techniquement changé.
La réaction habituelle consiste à empiler des !important pour forcer la priorité du nouveau CSS. Cette approche fonctionne à court terme, mais elle rend la feuille de style suivante tout aussi difficile à faire prévaloir : chaque nouveau conflit ajoute un !important supplémentaire, jusqu’à ce que plus aucune règle ne puisse être surchargée proprement.
Ce que fait réellement @layer
La règle CSS @layer introduit un ordre de priorité indépendant de la spécificité des sélecteurs. Deux règles de spécificité identique, placées dans deux couches différentes, ne se départagent plus par l’ordre d’apparition dans le fichier, mais par l’ordre de déclaration des couches elles-mêmes. Une couche déclarée plus tard l’emporte sur une couche déclarée plus tôt, quelle que soit la spécificité des sélecteurs qu’elle contient.
@layer theme-legacy, woocommerce-blocks, surcharges-projet;
@layer theme-legacy {
.woocommerce ul.cart li {
padding: 1rem;
border-bottom: 1px solid #ddd;
}
}
@layer surcharges-projet {
.wc-block-cart-item {
padding: 1.5rem;
border-bottom: 1px solid var(--couleur-bordure);
}
}
Isoler le CSS legacy du thème dans sa propre couche
La première étape de la réorganisation a consisté à envelopper l’intégralité du CSS existant du thème dans une couche nommée theme-legacy, sans modifier une seule règle interne. Cette étape, purement mécanique, suffit déjà à faire reculer ce CSS derrière n’importe quelle couche déclarée après lui, y compris le CSS natif de WooCommerce Blocks qui, lui, reste hors couche par défaut.
Ce point mérite d’être précisé : les styles déclarés sans @layer ne rejoignent aucune couche nommée, mais ils forment une couche implicite qui l’emporte toujours sur toutes les couches nommées, quel que soit leur ordre de déclaration. Il faut donc soit envelopper également le CSS natif de WooCommerce Blocks dans une couche explicite si l’on souhaite pouvoir le surclasser, soit s’assurer que les surcharges du projet restent, elles aussi, hors couche.
Ordonner les couches selon la stratégie du projet
Sur ce projet, l’ordre retenu place les couches dans cet enchaînement :
theme-legacy: tout le CSS hérité du thème, jamais modifié directement.woocommerce-blocks-personnalise: une couche dédiée aux surcharges volontaires du CSS natif des blocs.- Hors couche : les ajustements ponctuels et exceptionnels, qui restent volontairement rares.
Cette hiérarchie explicite remplace un empilement de !important par une déclaration lisible en une seule ligne, en tête de feuille de style, qui documente immédiatement l’ordre de priorité voulu pour l’ensemble du projet.
Un schéma pour visualiser la hiérarchie retenue
@layer theme-legacy, woocommerce-blocks-personnalise;
|
+-- theme-legacy (priorité la plus faible)
| `-- ancien CSS du thème, encapsulé sans modification
|
+-- woocommerce-blocks-personnalise (priorité intermédiaire)
| `-- surcharges volontaires des blocs Panier et Paiement
|
+-- (hors couche, priorité la plus forte)
`-- ajustements exceptionnels, à limiter au strict nécessaire
Compatibilité et prudence sur les anciens navigateurs
Les cascade layers bénéficient d’un support large dans les navigateurs modernes, mais un projet qui doit encore composer avec des navigateurs très anciens doit prévoir une dégradation contrôlée : sans lecture de @layer, un navigateur applique simplement l’ordre naturel de la cascade, ce qui peut réintroduire certains conflits. Un test ciblé sur le parc de navigateurs réellement utilisé par les clients du site reste indispensable avant généralisation.
Le vrai bénéfice des cascade layers n’est pas seulement technique : c’est la lisibilité. Un développeur qui rejoint le projet comprend en une ligne l’ordre de priorité voulu, là où un empilement de !important ne raconte plus aucune histoire cohérente.
En résumé
Face à un thème hérité en conflit avec le CSS natif de WooCommerce Blocks, les cascade layers offrent une solution plus durable que l’empilement de !important : elles rendent l’ordre de priorité explicite, documenté, et modifiable sans devoir réécrire les sélecteurs eux-mêmes. Cette réorganisation reste circonscrite au CSS natif des blocs et du thème ; elle ne couvre pas les éventuels blocs Elementor présents ailleurs sur le site, qui suivent leur propre logique de priorité.
