Formation « Créer des blocs avec Gutenberg »

Ajouter des styles CSS avec Sass

Lecture : 6 minutes • 0

Dans ce cours nous allons ajouter une couche de CSS grâce à Sass qui est inclut en standard dans create-block et qui compilera automatiquement nos fichiers sans effort.

Notre exemple : un bloc titre de chapitre

Pour ce cours j’ai créé un bloc que vous trouverez dans src/8-css. C’est un bloc titre un peu plus évolué avec une numérotation, pouvant être utilisé pour délimiter par exemple des chapitres :

Le bloc chapitre décoré en CSS

Il dispose de deux zones éditables : le numéro et le titre de la section que l’on va traduire bien entendu par 2 attributs, qui seront gérés par des composants RichText.

Les 2 feuilles de styles du blox

Pour le décorer on va utiliser les deux feuilles de style à notre disposition dans le bloc, 

  • style.scss  pour les styles principaux du bloc ;
  • editor.scss pour faire des ajustements dans l’éditeur uniquement.

Comme on va le voir dans ce cours, certains conflits apparaissent dans l’éditeur, qu’il nous conviendra de corriger via cette dernière feuille de style qui ne sera donc pas utilisée sur le site.

On va maintenant avoir besoin d’importer ces fichiers de style dans notre Javascript. Non pas qu’il en ait réellement besoin dans l’immédiat. Mais ça va permettre à Webpack, lors de la compilation, de prendre en compte ces styles afin qu’il les intègre à la feuille de style principale.

On importe en général style.css dans index.js :

JSX
src/8-css/index.js

Et la feuille de style pour l’éditeur, comme elle ne sert que dans la méthode Edit, sera uniquement intégrée dans edit.js, si besoin :

JSX
src/8-css/edit.js

Pour rappel :

  • Les editor.scss  de chaque bloc finiront dans build/index.css ;
  • Alors que les style.scss  iront dans dist/style-index.css.

D’ailleurs, la feuille de style index.css est chargée seulement dans l’admin WordPress.

Donc le principe est le suivant : les styles de votre bloc iront dans style.scss, alors que editor.scss servira uniquement à faire des ajustements sur l’éditeur Gutenberg.

Le code JSX

On va en profiter pour regarder plus en détails le JS ! Dans index.js, on y trouve 2 attributs :

JSX
src/8-css/index.js

Le premier servira pour stocker le numéro et un autre pour le titre. les sélecteurs pointent respectivement vers .number et .title que l’on devra donc retrouver dans la méthode save.

JS
src/8-css/save.js

Dans edit on retrouve les deux RichText, le premier situé dans un paragraphe à côté du #. J’ai ajouté quelques classes comme .first-line qui me permettra de cibler ma première ligne pour le CSS.

JSX
src/8-css/edit.js

Attention

Rappelez-vous d’utiliser className et non pas class dans votre HTML, car il va être interprété par JSX et le mot class est réservé au langage, ce qui causerait des erreurs.

Au début ça m’est souvent arrivé d’oublier ce détail, et mon style CSS n’était pas appliqué. Alors pensez-y ! Rappelez-vous aussi qu’Emmet est compatible JSX et transformera un p.first-line en <p className="first-line">.

Le CSS avec Sass

Allons faire un tour du côté du CSS. Commençons avec le fichier style.scss :

Sass
src/7-css/style.scss

Ici rien de particulier, le code est assez simple.

La classe du bloc nous est donnée directement par Gutenberg en fonction du slug qu’on lui a fourni en suivant ce schéma :

.wp-block-<slugplugin>-<slugblock> { }

En utilisant Sass on peut créer des variables et imbriquer les propriétés les unes dans les autres.

Si vous n’êtes pas à l’aise avec les préprocesseurs, vous pouvez toujours écrire du CSS natif ici. Mais prenez tout de même 5 minutes sur la documentation de Sass pour vous familiariser avec cette technologie, vous gagnerez ensuite énormément de temps.

Découvrir Sass

Surcharger les styles de base

Si vous essayez tel quel, vous verrez que l’aperçu dans l’éditeur n’est pas bon. Cela vient du fait que votre bloc hérite de certains styles de Gutenberg à cause du principe d’héritage du CSS.

C’est pour cela qu’on va avoir besoin de editor.scss qui va nous permettre de surchager ces styles, seulement dans l’éditeur.

Sass
src/7-css/editor.scss

En général, on commence toujours par la classe .editor-styles-wrapper car c’est celle qui englobe l’éditeur de blocs. C’est grâce à elle qu’on va pouvoir surcharger facilement les styles de l’éditeur.

Dans cet exemple, le champ RichText apporte son lot de styles par défaut : la taille du texte, les marges, la hauteur de ligne et la couleur ne sont pas bonnes.

Du coup, j’ai surcharger les styles afin de corriger ça. L’objectif est que le rendu dans l’éditeur soit 100% exact à celui sur le site.

Conseil

Pensez toujours à vérifier le rendu sur le site afin de contrôler qu’il est cohérent avec ce qui est affiché dans l’éditeur. Si ce n’est pas le cas, corrigez les styles dans editor.scss.

Les blockProps

Avez-vous remarqué qu’à aucun moment on écrivait nous-même le nom de la classe du bloc ? Car en réalité, c’est Gutenberg qui s’en occupe pour nous via les blockProps.

JSX

Ce sont des données qui sont ajoutées sous formes d’attributs HTML à notre bloc, et la classe CSS en fait partie.


Voilà pour notre bloc stylisé ! On pourrait aller encore plus loin, mais en peu d’efforts on a quelque chose de joli et opérationnel.

En vrai à terme le numéro de chapitre pourrait être automatisé mais ça demande de faire du JS hors du bloc pour trouver les autres et mettre à jour le comptage. Et mine de rien c’est tout de suite plus complexe à réaliser. On va donc rester sur une numérotation manuelle.

Conflits et héritage CSS

Avant de conclure je reviens sur cette histoire de conflits CSS. C’est toute une histoire, surtout dans l’univers de WordPress.

Le gros souci en réalité c’est justement de principe d’héritage du CSS : notre bloc hérite des styles de Gutenberg, et même de l’administration WordPress en général.

Et croyez-moi que c’est frustrant car il faut constamment « corriger » et « surcharger » vos styles pour que le rendu reste cohérent.

Et c’est la même chose en front selon le thème choisi ! Si c’est le votre, pas de souci, mais si c’est un thème premium par exemple, le risque est que vous allez récupérer tout un tas de styles indésirables.

Si j’essaie d’afficher mon bloc avec le thème twentyseventeen j’obtiens :

conflits CSS
conflits CSS avec le titre H2

Je remarque que le h2 a récupéré les marges définies par .wp-content h2. Ce thème a tendance à souligner tous les liens, du coup vous serez obligé d’annuler ce comportement au sein de vos blocs.

Au final on n’a pas le choix, il faut surcharger et penser à tout ce qui pourrait influencer vos styles de base. Dans le cas de notre titre il faut simplement appliquer une marge et un padding à 0 pour corriger le tir.

Conseil

Aussi fou que cela puisse paraitre, il n’existe aucun moyen aujourd’hui de stopper la propagation des styles CSS dans les surcharger.

C’est assez frustrant au jour le jour, mais c’est également le quotidien des développeurs d’extensions qui viennent ajouter des éléments dans votre site (via shortcode ou autre). Au final on se retrouve avec des sélecteurs CSS ultra chargés et c’est parfois difficile de s’y retrouver.

Conseil : la notation BEM

Je ne sais pas si vous la connaissez, mais je l’utilise depuis longtemps dans mes projets. La notation BEM permet de limiter les dégâts de conflit en ayant une approche de nommage des classes selon qu’ils représentent des blocs, éléments, ou modifieurs.

Vous retrouverez un guide à ce sujet ici.

La notation BEM en CSS
La notation BEM en CSS

Cela ne va pas corriger les problèmes sus-cités mais ça vous aidera à ne pas en créer davantage. BEM n’est pas une librairie ou un préprocesseur, c’est juste une façon de nommer ses classes CSS afin de rester cohérent dans ses projets.

Styled Components

Il y a aussi une autre technique utilisée par les applications web qui tournent sous React, c’est d’utiliser la librairie Styled component : en fait chaque composant a son propre CSS (et la classe est nommée automatiquement avec des chiffres et lettres pour être unique).

De cette manière il n’y a plus de CSS global : chaque composant a ses propres styles. Même si on pourrait utiliser cette technique pour nos blocs, cela ne résoudrait pas le problème général, puisque WordPress, Gutenberg, les thèmes et extensions n’utilisent pas ce système (et ne sont pas faits en React).


Bref, vous savez maintenant créer des styles pour vos blocs et tirer partie de la configuration automatique de create-block.

Gardez simplement à l’esprit qu’il faudra toujours bien les tester pour corriger au maximum les conflits de style CSS.

Dans le prochain cours, on va jouer avec un bloc alerte qui pourra changer de style en fonction du message.

0

Questions, réponses et commentaires

Laisser un commentaire