Dans les constructeurs visuels comme Elementor ou Divi, un bouton « Flex Extend » ou « Grow » propose d’étirer un composant pour qu’il remplisse l’espace disponible. Ce réglage ne correspond à aucune propriété CSS officielle. Il génère en coulisses un flex-grow: 1 ou une déclaration raccourcie flex: 1 1 0%, selon le builder utilisé.
La question du choix entre ce mécanisme et une largeur fixe (width) revient souvent dans les forums et les groupes d’entraide. Les retours terrain divergent sur ce point, car la réponse dépend du type de composant, du contexte de layout et du niveau de contrôle attendu.
Flex Extend : ce que le bouton génère dans le CSS compilé
Aucune spécification W3C ne mentionne « Flex Extend ». Ce label est une abstraction d’interface, créée pour rendre flex-grow accessible sans écrire de code. Quand on inspecte le DOM après activation dans Elementor, on retrouve systématiquement flex-grow: 1 ou flex: 1 1 0% sur l’élément ciblé.
Divi procède de façon similaire, parfois avec flex: 1 1 auto selon la version du builder. La différence entre 0% et auto comme valeur de flex-basis n’est pas anodine : elle modifie la base de calcul à partir de laquelle l’espace restant est distribué.
Un développeur qui travaille en code ne rencontrera jamais le terme « Flex Extend » dans la documentation officielle. Cette couche d’abstraction simplifie la prise en main, mais masque le comportement réel du layout, ce qui complique le débogage dès qu’un composant ne se comporte pas comme prévu.
Width classique en CSS : un dimensionnement explicite et ses limites
Poser un width: 300px ou un width: 50% sur un composant donne un résultat prévisible. Le navigateur applique la valeur telle quelle, sans redistribution d’espace. C’est le comportement attendu dans un modèle de boîte classique.
Cette approche fonctionne bien pour des composants dont la taille ne doit pas varier : un logo, un bouton d’action, un encart latéral à largeur fixe. En revanche, elle impose de recourir à des media queries dès que le layout doit s’adapter à plusieurs tailles d’écran.
Le problème apparaît sur les interfaces fluides. Multiplier les points de rupture pour ajuster chaque width alourdit la feuille de style et crée des cas limites difficiles à tester. C’est précisément le scénario où flex-grow prend le relais.
Distribution de l’espace restant : le calcul derrière flex-grow
Le mécanisme de flex-grow repose sur un principe simple : l’espace libre du conteneur est réparti proportionnellement entre les éléments qui acceptent de grandir. Si trois éléments ont chacun flex-grow: 1, ils se partagent l’espace en parts égales. Si l’un porte flex-grow: 2, il reçoit le double de l’espace supplémentaire par rapport aux autres.
Ce calcul ne remplace pas width. Il intervient après que le navigateur a déterminé la taille initiale de chaque élément (via flex-basis ou le contenu intrinsèque). Les deux propriétés coexistent dans la chaîne de dimensionnement, et c’est leur combinaison qui produit le résultat final.
Le piège de min-width: auto
Par défaut, un élément flex ne peut pas rétrécir en dessous de la taille de son contenu. Cette valeur implicite de min-width: auto provoque des débordements quand le contenu (texte long, image non contrainte) dépasse l’espace calculé par flex-grow.
La correction consiste à poser min-width: 0 ou overflow: hidden sur l’élément concerné. Sans cette précaution, activer Flex Extend sur un bloc contenant du texte libre peut casser le layout sur mobile.
Combiner flex-grow et width avec des garde-fous : le pattern recommandé
Les guides récents convergent vers un pattern hybride plutôt qu’un choix binaire. La déclaration flex: 1 1 150px (ou flex: 1 1 300px selon le composant) combinée à un max-width permet d’obtenir des cartes qui se redimensionnent et se répartissent sans media queries, tout en empêchant qu’une seule carte ne prenne toute la largeur.
Voici les garde-fous à poser systématiquement quand on utilise flex-grow sur un composant :
flex-basisavec une valeur minimale en pixels ou en rem, pour définir le seuil en dessous duquel l’élément passe à la ligne (avecflex-wrap)max-widthpour éviter qu’un élément seul sur sa ligne ne s’étire sur toute la largeur du conteneurmin-width: 0sur les éléments contenant du texte ou des médias, pour neutraliser le débordement par défaut
Ce pattern rend la question « flex-grow ou width » largement obsolète : les deux propriétés travaillent ensemble, chacune couvrant les angles morts de l’autre.
Performance et profondeur du DOM dans Elementor
Le choix entre Flex Extend et width sur un composant isolé a un impact négligeable sur les performances. En revanche, la migration globale vers des conteneurs Flexbox ou Grid dans Elementor (au lieu des anciennes sections) réduit de façon notable la profondeur du DOM.
Les recommandations récentes de performance pour Elementor insistent sur la conversion des anciennes sections en containers flex. Cette opération diminue le nombre de balises imbriquées, ce qui améliore les scores Core Web Vitals bien davantage que le réglage unitaire d’un flex-grow.
Si vous travaillez encore avec des sections classiques dans Elementor, la priorité est de migrer vers les containers flex avant de vous interroger sur le dimensionnement de chaque composant.
Quand choisir width, quand activer flex-grow
Le choix dépend de la nature du composant et de son rôle dans le layout. Quelques repères concrets :
- Un composant à taille fixe (logo, icône, sidebar contrainte) :
widthexplicite, sansflex-grow - Une carte dans une grille fluide qui doit occuper l’espace disponible :
flex-growavecflex-basisetmax-width - Un conteneur principal à deux colonnes (sidebar + contenu) :
widthfixe sur la sidebar,flex-grow: 1sur le contenu - Un élément dans un builder visuel sans accès au code : Flex Extend activé, puis vérification via l’inspecteur du navigateur pour contrôler la déclaration générée
Dans un builder visuel, activer Flex Extend sur tous les enfants d’un conteneur produit souvent des hauteurs incohérentes et des sur-étirements. Les guides récents recommandent de cibler le grow sur quelques composants clés (cartes, blocs de texte à remplir) plutôt que de l’appliquer de façon systématique.
La réponse à la question initiale tient en une ligne : ni l’un ni l’autre en exclusivité. Le dimensionnement fiable d’un composant flex repose sur la combinaison de flex-basis, flex-grow et de contraintes min/max, que l’on passe par un bouton d’interface ou par du CSS écrit à la main.
