Un intégrateur qui construit un thème hybride sans étape de build a-t-il vraiment besoin de Sass pour structurer son CSS ? La question se pose avec plus d’insistance depuis que la CSS Nesting Module Specification progresse dans les navigateurs. L’idée est simple : écrire directement, dans un fichier style.css classique, des règles imbriquées les unes dans les autres, sans qu’aucune étape de compilation ne les transforme au préalable en sélecteurs plats.
Dans un thème de blocs livré sans outillage de build — situation fréquente pour un site vitrine léger — cette possibilité change la façon d’organiser les styles qui complètent theme.json. Voici comment l’utiliser aujourd’hui, avec les précautions que son support encore inégal impose.
Étape 1 : repérer ce qui reste hors de theme.json
theme.json couvre les couleurs, les espacements et la typographie des blocs, mais pas les sélecteurs composés qui ciblent des états ou des combinaisons précises, par exemple un lien actif à l’intérieur d’un bloc navigation imbriqué dans un en-tête collant. Ces cas continuent de vivre dans un fichier style.css classique, enregistré avec wp_enqueue_style() depuis functions.php.
Étape 2 : écrire la première règle imbriquée
La syntaxe native reprend l’esperluette héritée de Sass pour référencer le sélecteur parent. Voici un en-tête de site dont le lien du bloc navigation change de couleur au survol, sans dupliquer le sélecteur parent :
.site-header {
background-color: var(--wp--preset--color--background);
.wp-block-navigation {
font-size: var(--wp--preset--font-size--small);
a:hover {
color: var(--wp--preset--color--primary);
}
}
}Le résultat compilé par le navigateur équivaut à trois sélecteurs distincts, sans qu’aucun outil n’ait retraité le fichier : c’est le moteur CSS lui-même qui interprète l’imbrication au moment du rendu.
Étape 3 : vérifier le support avant de s’y fier
À cette date, la prise en charge reste incomplète. Chrome et Edge l’implémentent depuis leur version 112, Safari depuis la 16.5, mais Firefox ne l’affiche encore que derrière un indicateur expérimental. Pour un site dont l’audience inclut une part significative d’utilisateurs de Firefox, retirer un préprocesseur maintenant reviendrait à casser silencieusement une partie des styles pour ces visiteurs.
Un repli simple avec @supports
La règle @supports permet de vérifier la prise en charge de la syntaxe imbriquée elle-même et de fournir un style de repli plat pour les navigateurs qui ne l’interprètent pas :
@supports not selector(>) {
.site-header .wp-block-navigation a:hover {
color: var(--wp--preset--color--primary);
}
}Étape 4 : garder une organisation lisible
La tentation, une fois l’imbrication disponible, est d’empiler quatre ou cinq niveaux dans un seul bloc. Nous limitons l’imbrication à deux niveaux au-delà du sélecteur racine, pour deux raisons pratiques :
- au-delà, la spécificité du sélecteur final devient difficile à anticiper sans rouvrir les outils de développement du navigateur ;
- un fichier trop imbriqué redevient aussi difficile à parcourir qu’un fichier Sass compilé, ce qui annule une partie du bénéfice recherché.
Ce que la nesting native ne remplace pas encore
Les variables, les boucles @each ou les fonctions de couleur de Sass n’ont pas d’équivalent natif à ce stade. Un thème qui utilisait Sass principalement pour ses fonctions de calcul de couleur ou ses mixins n’a pas de raison de l’abandonner ; celui qui ne s’en servait que pour imbriquer des sélecteurs peut, lui, s’en passer dès aujourd’hui, à condition d’assumer le repli pour Firefox.
Nous ne retirons un préprocesseur d’un projet existant qu’après avoir vérifié, fichier par fichier, qu’aucune fonction Sass n’est utilisée ailleurs que pour l’imbrication : c’est souvent la vraie raison qui justifie de le garder encore un peu.
Pour aller plus loin
Sur un nouveau projet sans contrainte d’audience ancienne, écrire directement en CSS imbriqué simplifie la chaîne d’outils : plus de watcher, plus de dépendance Node à maintenir pour un simple fichier de styles. Sur un projet existant, la bascule mérite d’attendre que le support touche une part suffisante du trafic réel du site, mesurée plutôt que supposée.
