Deux blocs, deux réglages de couleur de fond en apparence identiques, deux résultats HTML différents : l’un produit une classe has-background combinée à has-vivid-red-background-color, l’autre un style="background-color:#ff003c" directement sur la balise. Ce n’est pas un hasard ni une incohérence de WordPress : c’est la classe interne WP_Block_Supports qui décide, support par support, entre ces deux sorties.
Ce qu’est WP_Block_Supports
WP_Block_Supports est la classe PHP interne au cœur de WordPress qui orchestre l’application des « supports » déclarés dans block.json (couleur, typographie, espacement, bordure…) au moment du rendu d’un bloc. Chaque support (color, typography, spacing, border, etc.) enregistre auprès d’elle un callback de rendu via WP_Block_Supports::get_instance()->register(), callback exécuté automatiquement lors du filtre render_block pour ajouter les classes et styles nécessaires à la balise racine du bloc.
Fonctionnement interne : presets contre valeurs libres
La distinction entre classe CSS et style inline suit une logique précise, liée à l’origine de theme.json : lorsqu’une valeur provient d’un préréglage défini dans theme.json (une couleur de la palette, une taille de police nommée), le support génère une classe utilitaire prévisible, par exemple has-vivid-red-background-color ou has-large-font-size. Ces classes correspondent à des règles déjà générées globalement par WordPress dans une feuille de style, ce qui évite de dupliquer la même valeur en style inline sur chaque bloc qui l’utilise.
Lorsque la valeur provient en revanche d’une saisie libre de l’utilisateur (un code hexadécimal choisi via le sélecteur de couleur personnalisé, une taille de police en pixels tapée à la main), aucune classe globale ne peut la représenter : WordPress génère alors un style inline directement sur la balise, car aucune règle CSS partagée ne préexiste pour cette valeur précise.
Où regarder dans le code pour comprendre un cas précis
Le fichier wp-includes/block-supports/colors.php illustre bien ce mécanisme : la fonction qui applique le support couleur vérifie d’abord si la valeur transmise correspond à un slug de préréglage (au format var:preset|color|nom-du-slug une fois résolu), auquel cas elle ajoute une classe ; sinon, elle construit un attribut style avec la valeur brute. Le même schéma se retrouve dans les fichiers dédiés à la typographie, à l’espacement et aux bordures, chacun avec ses propres règles de nommage de classes.
Un exemple de sortie générée
<!-- Valeur issue d'un préréglage de la palette -->
<div class="wp-block-group has-vivid-red-background-color has-background">
<!-- Valeur libre saisie par l'utilisateur -->
<div class="wp-block-group has-background" style="background-color:#ff003c">Cas d’usage : diagnostiquer un style qui semble ignoré
Comprendre ce mécanisme aide à résoudre un problème fréquent : une règle CSS personnalisée qui cible .has-vivid-red-background-color ne s’applique pas à un bloc dont l’utilisateur a choisi une couleur personnalisée, car ce bloc ne porte pas cette classe, seulement un style inline. La correction ne consiste pas à renforcer la spécificité CSS de la règle, mais à comprendre que deux mécanismes distincts coexistent et qu’ils demandent des sélecteurs différents (ou, mieux, à restreindre les couleurs disponibles aux préréglages de theme.json pour garantir une sortie homogène).
- Vérifier d’abord si la valeur en cause provient d’un préréglage ou d’une saisie libre.
- Adapter les règles CSS personnalisées pour couvrir les deux cas si les deux restent autorisés.
- Envisager de limiter les options de couleur ou de typographie aux préréglages si l’homogénéité du rendu prime sur la liberté de saisie.
Pièges à connaître
Un support personnalisé mal enregistré peut produire un style inline dupliqué si son callback ne vérifie pas l’origine de la valeur avant de construire l’attribut style. Autre piège plus subtil : la fusion des styles inline provenant de plusieurs supports (couleur, espacement, bordure) se fait dans un ordre déterminé par leur enregistrement, ce qui peut, dans de rares cas de conflit de propriété CSS, faire gagner un support sur un autre de façon peu intuitive si l’on ignore cet ordre.
En résumé
Le choix entre classe CSS et style inline n’a rien d’arbitraire : il reflète directement l’origine de la valeur, préréglage de theme.json ou saisie libre de l’utilisateur. Cette distinction, portée par WP_Block_Supports et ses callbacks par support, explique la plupart des surprises rencontrées en tentant de cibler par CSS un réglage qui semble identique en apparence mais diffère en réalité dans son mode de sortie.
