# editorStyle contre style dans block.json : où vit chaque CSS

> Deux propriétés qui se ressemblent dans block.json, deux fichiers CSS distincts, deux endroits de chargement totalement différents. Confondre les deux double le travail.

- Auteur : Clément Hadrot
- Publié le : 2022-09-28
- Mis à jour le : 2022-09-28
- Catégorie : Blocs Gutenberg
- URL : https://wpmoderne.dev.wordpress-developpement.fr/blocs/editorstyle-style-block-json-ou-vit-css/

## L’essentiel

- style se charge à la fois dans l'éditeur et sur le front
- editorStyle ne se charge que dans l'interface d'édition
- Dupliquer son CSS entre les deux vient souvent de cette confusion

Un développeur débutant sur les blocs Gutenberg avait fini par dupliquer intégralement son fichier CSS en deux copies quasi identiques, l'une chargée côté front, l'autre côté éditeur, avec quelques ajustements ponctuels pour compenser des différences d'affichage entre les deux contextes. Cette duplication, source d'incohérences à chaque modification oubliée d'un seul côté, provenait d'une incompréhension simple mais rarement expliquée clairement : la différence entre les propriétés `style` et `editorStyle` de `block.json`.

Ces deux propriétés ne sont pas redondantes : elles ciblent des contextes de chargement distincts, et bien comprendre leur rôle respectif permet d'éviter la duplication de CSS qui piège tant de développeurs débutant sur les blocs.

## style : le CSS qui vit partout

La propriété `style` déclare une feuille de style chargée à la fois sur le front du site et dans l'éditeur de blocs. C'est l'endroit naturel pour tout le CSS qui définit l'apparence réelle du bloc telle qu'un visiteur la verra : couleurs, espacements, mise en page, tout ce qui doit rester visuellement identique entre l'aperçu dans l'éditeur et le rendu final publié.

```
{
  "style": "file:./style-index.css"
}
```

## editorStyle : le CSS réservé à l'interface d'édition

La propriété `editorStyle`, elle, ne charge son fichier que dans le contexte de l'éditeur, jamais sur le front du site. Elle est destinée aux ajustements purement liés à l'expérience d'édition : une bordure en pointillé pour matérialiser une zone de dépôt, un curseur différent au survol, un espacement supplémentaire pour compenser la présence de la barre d'outils contextuelle qui n'existe pas côté front.

```
{
  "editorStyle": "file:./index.css"
}
```

> L'essentiel à retenir : style se charge à la fois dans l'éditeur et sur le front ; editorStyle ne se charge que dans l'interface d'édition ; Dupliquer son CSS entre les deux vient souvent de cette confusion

## Un exemple concret pour fixer les idées

Pour un bloc « Carte produit » avec une bordure au survol utile uniquement pendant l'édition :

```
/* style-index.css : chargé partout, définit l'apparence réelle */
.wp-block-mon-agence-carte-produit {
    padding: 1.5rem;
    border-radius: 0.5rem;
}

/* index.css : chargé uniquement dans l'éditeur */
.wp-block-mon-agence-carte-produit:hover {
    outline: 1px dashed #2563eb;
}
```

Cette séparation évite qu'un visiteur du site ne voie jamais cette bordure en pointillé, purement utile au rédacteur pendant la composition de la page, sans qu'il soit nécessaire d'ajouter une classe conditionnelle en JavaScript pour distinguer les deux contextes.

## Pourquoi la duplication apparaît si souvent

La confusion vient généralement du fait que la plupart des tutoriels commencent par un seul fichier CSS et n'introduisent `editorStyle` que plus tard, une fois un besoin spécifique à l'éditeur identifié. Sans cette distinction claire dès le départ, le réflexe naturel est de tout mettre dans un seul fichier chargé par les deux propriétés à la fois, ce qui fonctionne mais perd l'intérêt principal de la séparation : la possibilité d'ajuster librement l'expérience d'édition sans jamais risquer d'impacter le rendu public.

| Propriété | Chargé sur le front | Chargé dans l'éditeur |
| --- | --- | --- |
| `style` | Oui | Oui |
| `editorStyle` | Non | Oui |

## Le cas particulier de @wordpress/scripts

Avec l'outillage officiel `@wordpress/scripts`, la convention de nommage des fichiers source facilite cette séparation automatiquement : un fichier `style.scss` à la racine du bloc produit le CSS partagé référencé par `style`, tandis qu'un fichier `editor.scss` produit celui référencé par `editorStyle`, sans configuration supplémentaire à écrire dans `webpack.config.js`.

- Commencer par se demander si un style doit être visible par un visiteur du site, pas seulement par le rédacteur.
- Réserver editorStyle aux seuls ajustements d'expérience d'édition, jamais à de l'apparence finale.
- Vérifier régulièrement qu'aucune règle utile au front ne s'est glissée par erreur dans le fichier réservé à l'éditeur.

> Si une règle CSS doit rester invisible pour un visiteur, elle appartient à editorStyle. Si elle doit être visible pour tout le monde, elle appartient à style. Il n'existe pas de troisième cas.

## Ce qu'il faut retenir

La distinction entre style et editorStyle répond à un besoin réel de séparation des préoccupations entre rendu public et confort d'édition, pas à une redondance historique du format block.json. Une fois cette distinction intégrée, la tentation de dupliquer un même fichier CSS en deux copies presque identiques disparaît d'elle-même, remplacée par deux fichiers courts, chacun avec une responsabilité claire et non ambiguë.