16 pixels invisibles séparent deux blocs qui, sur la maquette validée par le client, devaient se toucher presque exactement. Sur l’écran, l’œil ne voit pas grand-chose d’anormal : juste un espace un peu généreux entre une image et le texte qui suit. C’est en superposant la maquette Figma à l’export réel que la différence saute aux yeux, au pixel près.
Ce genre de décalage, sur un projet migré des Sections vers les Containers Flexbox, revient plus souvent qu’on ne le pense. Il ne s’agit pas d’un bug d’Elementor, mais d’une addition parfaitement logique que la migration rend simplement plus fréquente : le gap du Container flexbox et la marge d’un widget enfant s’ajoutent l’un à l’autre au lieu de se fondre.
Le symptôme : un espacement qui double sans raison apparente
Le cas type ressemble à ceci : un Container en disposition verticale (flex-direction: column) contient trois widgets. Le Container a un espacement défini dans l’onglet Mise en page, section « Gap », réglé par exemple à 24px. Un des widgets enfants, un titre ou une image, conserve en plus une marge basse héritée d’un ancien style de Section, réglée dans l’onglet Avancé sur 16px.
Résultat visible dans le rendu final : 40 pixels d’espace entre les deux éléments concernés, alors que les autres écarts du même Container affichent bien 24 pixels. Sur une page entière, ce genre d’écart isolé passe facilement inaperçu en relecture rapide, surtout si le reste de la mise en page est cohérent.
Le diagnostic : ouvrir l’inspecteur avant d’accuser Elementor
La méthode la plus rapide reste l’inspecteur du navigateur. En sélectionnant l’élément concerné, deux informations suffisent à trancher :
- La règle CSS générée par Elementor sur le Container parent, où figure la propriété
gap(ourow-gapselon la direction). - La règle CSS sur le widget enfant lui-même, dans sa boîte « Box model », qui affiche la marge additionnelle en surbrillance.
Dans la majorité des cas observés, la marge parasite provient d’un ancien style copié-collé depuis un gabarit hérité en Sections, où chaque widget devait porter sa propre marge puisque les Sections ne géraient pas d’espacement automatique entre enfants. Une fois le Container adopté, cette marge devient redondante mais personne ne pense à la retirer, puisque le rendu visuel reste globalement acceptable.
Le correctif : choisir un seul responsable de l’espacement
La règle à appliquer est simple à énoncer, plus difficile à faire respecter sur un gros gabarit : un seul élément décide de l’espacement entre deux blocs, jamais les deux à la fois. Concrètement, deux options s’offrent à l’intégrateur :
- Retirer la marge du widget enfant et laisser le
gapdu Container gérer l’intégralité de l’espacement, ce qui fonctionne bien tant que l’espacement doit rester uniforme entre tous les enfants. - Désactiver ou réduire le
gapdu Container à zéro et gérer l’espacement au cas par cas via les marges, utile quand un seul écart doit différer des autres.
Le code généré illustre bien le problème une fois les deux règles mises côte à côte :
.e-con.elementor-element-abc123 {
display: flex;
flex-direction: column;
gap: 24px;
}
.elementor-element-def456 {
margin-block-end: 16px;
}
Sur le rendu final, l’espace réel correspond bien à l’addition des deux valeurs, puisque le navigateur applique le gap entre les boîtes puis ajoute la marge de la boîte elle-même par-dessus. Il ne s’agit pas d’un cumul en apparence, mais d’un cumul réel dans le calcul du navigateur.
La prévention : une convention d’équipe plutôt qu’une correction au cas par cas
Sur un projet à plusieurs intégrateurs, la solution la plus durable consiste à écrire noir sur blanc une règle simple dans la documentation interne du thème : les marges verticales sur les widgets sont interdites dès qu’ils vivent dans un Container qui gère déjà un gap. Les seules exceptions tolérées sont documentées explicitement, avec la raison du choix.
Un espacement qui se voit deux fois dans le code source finit toujours par se voir une fois de trop à l’écran. Autant trancher la question avant la mise en production.
Un contrôle rapide avant livraison consiste à parcourir le panneau Navigator d’Elementor, sélectionner chaque Container un par un, et vérifier dans l’onglet Avancé qu’aucun enfant ne porte de marge verticale résiduelle. Sur un gabarit de taille moyenne, cette vérification prend rarement plus de dix minutes et évite des allers-retours de correction bien plus coûteux après la mise en ligne.
En résumé
Le doublon d’espacement entre un gap de Container et une marge de widget n’a rien d’un bug caché : c’est une conséquence directe et prévisible du modèle flexbox, amplifiée par les migrations qui conservent des habitudes héritées des Sections. Une convention d’équipe claire, associée à une vérification systématique du Navigator avant livraison, suffit à éliminer ce genre d’écart avant qu’il n’atteigne la production.
