Drupal Paragraphs: résoudre les lacunes d'espacement dans les layouts composants

Vous pouvez construire un excellent système de paragraphes et le voir quand même se désagréger la première fois qu'un rédacteur empile deux sections blanches l'une sur l'autre. L'espacement est le détail qui décide discrètement si un layout composant paraît soigné ou cassé.

L'espacement Drupal Paragraphs - les marges verticales et le padding entre et à l'intérieur des composants Drupal Paragraphs - est l'un de ces problèmes qui n'apparaissent jamais en démo et apparaissent toujours en production. Vous concevez chaque type de paragraphe pour qu'il soit parfait isolément. Les rédacteurs adorent la nouvelle flexibilité. Puis ils empilent deux paragraphes blancs et l'espace entre eux devient énorme. Ou ils suppriment un titre et une bande vide étrange reste là où se trouvait l'en-tête.

Tout système basé sur les paragraphes y arrive tôt ou tard. Nous l'avons rencontré dans notre distribution Droopler, sur des projets clients, et nous l'avons anticipé lors d'une récente reconstruction corporate. Cet article explique pourquoi les problèmes d'espacement sont inévitables, présente trois approches pour les résoudre, montre une implémentation concrète avec du code et décrit des scénarios réels de production qui déterminent l'approche dont vous avez réellement besoin.

Dans cet article :

• Pourquoi les problèmes d'espacement apparaissent toujours
• Trois approches pour contrôler l'espacement
• Implémenter le contrôle d'espacement sur vos paragraphes
• Scénarios réels d'espacement et comment les résoudre
• Bonnes pratiques pour l'espacement des paragraphes

Pourquoi les problèmes d'espacement apparaissent toujours

Lorsque vous créez un type de paragraphe pour la première fois, vous lui donnez un rythme vertical fixe : une marge en haut, une en bas, un padding interne. Il paraît parfait, parce que vous le testez sur le « happy path » - un paragraphe, tous les champs remplis, inséré entre deux autres sections bien comportées.

Le contenu réel ne reste pas sur le happy path. Les mêmes espacements fixes qui semblent équilibrés en démo commencent à poser problème dès que les rédacteurs combinent des composants de façons que vous n'aviez pas prévues :

• Deux paragraphes au même fond, empilés. Quand une section blanche repose directement sur une autre section blanche, leurs marges s'additionnent. Au lieu d'une séparation nette, vous obtenez une lacune énorme qui coupe visuellement la page en deux.
• Champs optionnels laissés vides. Un paragraphe avec un champ titre masqué ou vide laisse l'espace que le titre aurait occupé. Le résultat est une bande de blanc qui ressemble à une erreur.
• Sections qui devraient se lire comme un seul bloc. Parfois un rédacteur veut que deux paragraphes forment un bloc continu - sans couture visible. Les marges fixes rendent cela impossible, car il y a toujours un espace qui les repousse.
• Densités de contenu différentes. Un tableau de données dense et un court appel à l'action n'ont pas besoin du même « souffle ». Une valeur fixe ne peut pas convenir aux deux.

La cause est simple : l'espacement est contextuel, mais le CSS, par défaut, est absolu. Une valeur de marge ne sait pas si le paragraphe au-dessus est blanc ou sombre, plein ou vide, destiné à être séparé ou uni. Le rédacteur le sait. Le système non - à moins de donner au rédacteur un moyen de le signaler.

Trois approches pour contrôler l'espacement

Il n'existe pas une seule bonne façon de gérer l'espacement Drupal Paragraphs. Il y en a trois, et la bonne dépend de la variété de votre contenu et du niveau de contrôle dont vos rédacteurs ont besoin.

Approche 1 : espacement fixe sans contrôles

Chaque type de paragraphe est livré avec une seule valeur d'espacement codée en dur. Il n'y a aucune option dans le formulaire d'administration.

• Avantages : simple à construire, parfaitement cohérent, les rédacteurs n'ont jamais à décider.
• Inconvénients : casse à chaque cas limite ci-dessus, offre zéro flexibilité et génère discrètement des tickets dès que le contenu réel entre en conflit avec les valeurs fixes.
• Idéal pour : des sites simples aux layouts prévisibles, où les rédacteurs assemblent des pages à partir d'un ensemble restreint et bien compris de modèles.

C'est là que la plupart des projets commencent. C'est aussi là que la plupart finissent par rester bloqués, car la première lacune gênante se transforme en demande développeur que l'espacement fixe ne peut pas résoudre côté rédaction.

Approche 2 : espacement sélectionnable avec contrôles rédacteur

Chaque paragraphe expose des options d'espacement directement dans le formulaire d'édition. Le rédacteur choisit la marge et le padding parmi un petit ensemble de tailles nommées.

• Contrôle des marges : none / small / medium / large
• Contrôle du padding : none / small / medium / large
• Avantages : assez flexible pour gérer les cas limites sans développeur, et place la décision contextuelle là où le contexte vit réellement - avec le rédacteur sur la page.
• Inconvénients : un peu plus de complexité dans le formulaire d'administration ; sans garde-fous, cela peut mener à un espacement incohérent sur tout le site.
• Idéal pour : des sites corporate au contenu varié et des systèmes composants où le même paragraphe apparaît dans de nombreux contextes différents.

C'est l'approche que nous recommandons pour toute bibliothèque sérieuse de composants réutilisables. C'est aussi ce que nous avons fini par ajouter à Droopler et aux projets clients, une fois l'espacement fixe devenu trop rigide.

Approche 3 : espacement automatique et contextuel

Au lieu d'interroger le rédacteur, vous laissez le CSS détecter le contexte et s'adapter. Les sélecteurs de frères adjacents et les règles de fusion des marges peuvent, par exemple, supprimer la marge doublée quand deux paragraphes blancs se suivent.

• Avantages : invisible pour les rédacteurs, pas de champs supplémentaires, corrige automatiquement les cas les plus courants.
• Inconvénients : portée limitée, plus difficile à déboguer, fragile à mesure que la bibliothèque de composants grandit. Pire encore : l'espacement change d'une façon que le rédacteur ne voit ni ne contrôle - réordonnez deux paragraphes et la marge ou le padding se décale soudainement, sans raison évidente et sans moyen de corriger depuis le CMS.
• Idéal pour : des layouts plus simples, et seulement pour un tout petit nombre de cas vraiment évidents.

En pratique, nous recommandons l'approche 2 par défaut pour tout site non trivial. Le contrôle côté rédacteur garde l'espacement prévisible : ce que le rédacteur définit est ce qu'il obtient, et réordonner ou dupliquer un paragraphe ne produit jamais de surprise. C'est précisément cette prévisibilité que sacrifient les règles automatiques. Dès que l'espacement change tout seul - un rédacteur déplace une section et le padding change silencieusement - la confiance dans le CMS s'érode plus vite que n'importe quelle lacune excessive ne vous aurait coûté. Si vous utilisez des règles automatiques, gardez-les au strict minimum et laissez les rédacteurs contrôler le reste.

Implémenter le contrôle d'espacement sur vos paragraphes

Ajouter un espacement sélectionnable à un type de paragraphe n'est pas un gros travail. La mécanique suit le même modèle que pour les variantes de couleur : un champ select mappé sur une classe CSS.

L'implémentation se résume en quatre étapes.

1. Ajouter les champs. Créez deux champs list (text) sur le type de paragraphe, par exemple `field_margin` et `field_padding`. Donnez-leur les mêmes options : none, small, medium, large.
2. Rendre les valeurs en classes. Dans le template du paragraphe, lisez les valeurs des champs et appliquez-les comme classes modificatrices sur l'élément wrapper.
3. Définir une échelle d'espacement en CSS. Utilisez des custom properties pour que toute l'échelle vive au même endroit et reste cohérente entre les composants.
4. Définir des valeurs par défaut sensées. Présélectionnez medium pour que les rédacteurs ne modifient l'espacement que lorsque c'est nécessaire - pas sur chaque paragraphe.

Côté Twig, cela ressemble à ceci - lecture des deux champs et ajout des classes modificatrices :

{% set spacing_classes = [
  'paragraph--margin-' ~ (content.field_margin['#items'].value|default('medium')),
  'paragraph--padding-' ~ (content.field_padding['#items'].value|default('medium')),
] %}
<div{{ attributes.addClass('paragraph', spacing_classes) }}>
  {{ content|without('field_margin', 'field_padding') }}
</div>

Et le CSS, avec l'échelle définie une fois en custom properties :

:root {
  --space-s: 1.5rem;
  --space-m: 3rem;
  --space-l: 5rem;
}

.paragraph--margin-none   { margin-block: 0; }
.paragraph--margin-small  { margin-block: var(--space-s); }
.paragraph--margin-medium { margin-block: var(--space-m); }
.paragraph--margin-large  { margin-block: var(--space-l); }

.paragraph--padding-none   { padding-block: 0; }
.paragraph--padding-small  { padding-block: var(--space-s); }
.paragraph--padding-medium { padding-block: var(--space-m); }
.paragraph--padding-large  { padding-block: var(--space-l); }

Si vous ajoutez un peu de comportement automatique par-dessus - et nous le limiterions au strict minimum - restreignez-vous à un ou deux cas sans ambiguïté. Une seule règle de frère adjacent supprime par exemple la lacune doublée entre deux sections au même fond :

.paragraph--bg-white + .paragraph--bg-white {
  margin-block-start: 0;
}

C'est exactement le modèle que nous avons adopté pour Droopler. La décision clé a été d'exposer deux contrôles séparés plutôt qu'un seul. Marge et padding résolvent des problèmes différents : la marge éloigne un paragraphe de ses voisins, le padding règle l'espace à l'intérieur du paragraphe, entre le bord du fond et le contenu. Nous donnons aux rédacteurs trois tailles pour chacun. Cette combinaison couvre presque toutes les situations qu'un rédacteur rencontre, sans le submerger de réglages au pixel près.

Lisez aussi : une méthode rapide pour éditer et personnaliser un paragraphe Drupal et le module Geysir pour une édition de paragraphes plus rapide.

Scénarios réels d'espacement et comment les résoudre

Nous défendons si fermement le contrôle côté rédacteur parce que nous avons vu ces scénarios se produire en direct sur des projets. Aucun n'est hypothétique.

• Deux paragraphes blancs empilés. Le classique. Deux sections au même fond créent une marge doublée et une lacune énorme. La solution : le rédacteur met la marge supérieure du second paragraphe sur none, et les deux sections se lisent comme une seule.
• Un hero suivi d'une section de contenu. Un hero a besoin d'un autre « souffle » que deux blocs de contenu à la suite. Avec des marges sélectionnables, le rédacteur resserre ou assouplit la transition sans ticket.
• Un paragraphe sans titre. Supprimez le titre et l'espace réservé devient une bande vide gênante. Le rédacteur réduit le padding d'un cran et la lacune disparaît.
• Un paragraphe image pleine largeur. Les visuels bord à bord demandent généralement un padding nul pour ne rien les encadrer. L'option « none » règle cela immédiatement.
• Deux paragraphes qui doivent fusionner en un seul bloc. Quand un rédacteur ne veut aucune couture visible entre sections, seule une marge nulle entre eux fonctionne - et l'espacement fixe ne peut tout simplement pas le fournir.

Sur un projet client, l'espacement n'était pas un détail de finition mineur. C'était l'une des sources de friction les plus persistantes. La plateforme utilisait un modèle composant similaire, construit un peu différemment, et la bataille constante était : la bonne quantité d'espace dépendait entièrement du contenu. Parfois une section avait besoin de plus de place, parfois moins, et les sections empilées de même couleur « explosaient » toujours. Nous avons fini par ajouter des contrôles explicites - small, medium, large - pour que les rédacteurs puissent résoudre eux-mêmes. Droopler a suivi le même chemin : les contrôles d'espacement n'étaient pas là au départ, les mêmes problèmes sont apparus, et nous avons ajouté les réglages de marge et de padding.

Il y a aussi une leçon de planification dans cette histoire. Lors d'une récente reconstruction corporate, nous avons architecturé le système de paragraphes pour que les contrôles d'espacement puissent être ajoutés plus tard sans restructurer quoi que ce soit. Ce n'était pas dans le périmètre initial, mais tous les participants savaient par expérience que la demande viendrait. Le prévoir dès le départ transforme une future reconstruction en un futur changement de configuration.

Bonnes pratiques pour l'espacement des paragraphes

Quelques règles maintiennent l'espacement sous contrôle à mesure qu'une bibliothèque de composants grandit.

• Commencer sans contrôles, mais architecturer pour eux. Sur un petit site, vous pouvez lancer avec un espacement fixe. Ce qui ne va pas : construire le système de façon à ce qu'ajouter des contrôles plus tard exige une reconstruction douloureuse. Laissez la porte ouverte.
• Utiliser des CSS custom properties pour l'échelle. Définissez small, medium et large une fois. Quand le design évolue, vous changez trois valeurs au lieu de parcourir chaque composant.
• Limiter les options. Trois ou quatre tailles nommées suffisent. Le contrôle au pixel près semble séduisant, mais produit des pages incohérentes et de la fatigue décisionnelle. Les contraintes sont un atout.
• Documenter la logique d'espacement pour les rédacteurs. Un court guide visuel - à quoi ressemblent none, small, medium et large - transforme les approximations en choix sûrs. Le meilleur endroit est une page d'exemple en direct sur staging.
• Tester avec de vraies combinaisons de contenu. Les problèmes d'espacement n'apparaissent que quand les paragraphes se rencontrent. Testez les sections empilées au même fond, les champs optionnels vides et les blocs fusionnés - pas des paragraphes isolés dans le vide.

Le fil conducteur de tous ces points est le même que pour tout bon système de paragraphes : concevez pour la façon dont les rédacteurs combinent réellement les composants, pas pour la façon dont chaque composant paraît seul.

Vous voulez un espacement qui fonctionne simplement sur votre site Drupal ?

Cet article s'appuie sur une expérience de production réelle - l'intégration de contrôles d'espacement dans notre distribution Droopler, la lutte et la correction des mêmes problèmes sur des projets clients, et l'architecture d'un récent système Paragraphs corporate pour que les contrôles d'espacement puissent être ajoutés au moment où ils seront nécessaires. Le schéma se répète sur chaque construction composant, ce qui vaut la peine d'être planifié dès le départ.

Vous luttez avec des lacunes d'espacement dans vos propres layouts de paragraphes, ou vous planifiez un système composant que vous voulez bien faire du premier coup ? Notre équipe construit des implémentations Paragraphs adaptées aux rédacteurs - des contrôles d'espacement et de couleur à une architecture Twig et CSS propre. Visitez notre agence Drupal pour voir comment nous pouvons vous aider.