Un style écrit pour la variante « fond sombre » d’un bloc précis ne doit jamais s’appliquer, par accident, à un autre bloc qui partage la même classe générique ailleurs sur la page. Pour éviter ce genre de fuite, l’éditeur de blocs adopte une pratique de portée de style : les styles additionnels d’un bloc (styles de bloc, blocs stylés depuis le panneau Styles) sont automatiquement rattachés à un sélecteur suffisamment précis pour ne concerner que ce bloc particulier, sans effet de bord sur ses voisins.
Fonctionnement dans WordPress
Techniquement, cela s’appuie sur des classes générées automatiquement (comme is-style-nom-du-style combinée à la classe du bloc) plutôt que sur des sélecteurs génériques, et de plus en plus sur les calques de cascade (@layer) introduits pour séparer proprement les styles du cœur, du thème et des blocs. Depuis WordPress 6.6, certains styles générés pour l’éditeur profitent aussi d’une isolation renforcée grâce à la pseudo-classe :where(), qui garde une spécificité nulle tout en ciblant précisément le bloc concerné.
Exemple
:where(.wp-block-button.is-style-contour) .wp-block-button__link {
background: transparent;
border: 2px solid currentColor;
}À ne pas confondre avec
- CSS-in-JS, qui génère une portée de style en attribuant des noms de classes uniques à la compilation, une technique différente bien que poursuivant un objectif proche.
- Un simple espace de nom de classe (préfixer toutes ses classes par le nom du thème) : une convention utile mais qui ne garantit aucune isolation technique réelle, contrairement à une véritable portée gérée par l’outillage.
- Les calques de cascade, qui organisent la priorité entre grandes familles de styles (cœur, thème, blocs), alors que la portée de style concerne la précision du ciblage à l’intérieur d’un même calque.