Gutenberg et les media queries

Nous allons voir comment rendre adaptatif l’éditeur de WordPress, Gutenberg, afin qu’il supporte les mêmes points de rupture (breakpoints) que le front-end.

Habituellement, pour gérer les points de rupture en front-end, nous utilisons les requêtes média (media queries) qui nous permettent de modifier la mise en page des blocs en fonction de la taille de la fenêtre d’affichage (viewport).

Or, lorsqu’il s’agit de l’éditeur de WordPress, la largeur de la fenêtre d’affichage n’est pas une référence pertinente en raison de la présence des barres latérales à gauche (le menu principal de WordPress) et à droite (la barre des réglages de Gutenberg).

En effet, contrairement au front-end où le body contient l’ensemble du site, le contenu à éditer dans le back-end se trouve dans la div avec la classe .editor-styles-wrapper.

Il serait donc intéressant de pouvoir se référer à ce dernier élément, plutôt qu’au body, afin que son contenu se comporte de la même façon que se comporte le site lui-même.

Je vous propose d’appliquer le concept de container queries au bloc qui contient l’éditeur afin de palier l’effet inapproprié de l’utilisation de requêtes média. Pour résumer ce concept, qui n’est actuellement qu’à l’état de proposition d’amélioration de CSS faite par le RICG, disons qu’il s’agit de se référer à n’importe quel élément HTML, plutôt qu’uniquement à la fenêtre d’affichage, pour définir des points de rupture. Cette fonctionnalité, parfaitement adaptée à ce cas de figure, peut être simulée en javascript par l’ajout ou le retrait dynamique de classes en fonction de la largeur de l’élément en question. L’article de Philip Walton, « Responsive Components: a Solution to the Container Queries Problem« , va nous y aider…

Ajoutons donc à notre thème actif le fichier javascript qui contiendra une version légèrement adaptée du script original proposé par Pilip Walton et que nous appellerons par exemple editor-script.js :

L’objet breakpoints contient la liste des points de rupture avec le nom des classes qui leur sont associées. Il faudra évidemment adapter ces points de rupture à ceux du site. Le nom des classes est également indicatif.

Ces classes seront dynamiquement ajoutées ou supprimées du bloc avec la classe .block-editor__typewriter qui suit immédiatement le bloc racine, dont la classe est .editor-styles-wrapper, en fonction de la largeur de ce dernier. Pour que le bloc racine reproduise le comportement du body, il devra avoir une largeur de 100%.

On intègre ensuite ce fichier dans les pages de l’éditeur en utilisant le hook enqueue_block_editor_assets justement prévu à cet effet :

Nous pouvons dès lors nous servir des classes associées aux points de rupture, en lieu et place des requêtes média. Désormais nous sommes sûrs que la mise en page répondra aux mêmes points de rupture dans le back-end que dans le front-end. En effet, les points de rupture ne seront plus associés à la taille de la fenêtre d’affichage mais à celle du bloc racine qui contient l’éditeur. Que les barres latérales qui l’entourent soient ou non visibles n’y changera rien.

En voici un exemple :

Voila donc une méthode qui permettra de faire correspondre le comportement responsive de l’outil d’édition des contenus à celui du site.

Cet article vous a plu ? Partagez vos remarques et vos astuces dans les commentaires !