Le terme Flex Extend apparaît dans les interfaces d’Elementor, Divi ou Webflow sans correspondre à une propriété CSS. Activer cette option revient à poser un flex-grow sur le bloc ciblé, le plus souvent via la déclaration raccourcie flex: 1. Confondre les deux notions mène à des layouts bancals et à des heures de débogage inutiles.
Flex Extend dans les page builders : ce que le bouton active réellement
Aucune spécification W3C ni aucune page MDN ne mentionne une propriété appelée « Flex Extend ». Ce label est une invention d’interface, propre aux constructeurs visuels, pour rendre flex-grow accessible sans écrire de CSS.
A lire en complément : Combine GPX et kml : regrouper vos itinéraires randonnée en un clic
Quand nous inspectons le code généré par Elementor après activation de Flex Extend, nous trouvons systématiquement flex-grow: 1 ou flex: 1 1 0% appliqué à l’élément concerné. Divi procède de la même façon, parfois avec une valeur flex: 1 1 auto selon la version du builder.
La confusion naît du fait que Flex Extend n’est pas du CSS mais un raccourci d’interface. Un développeur qui lit la documentation officielle ne retrouvera jamais ce terme. Travailler en code plutôt qu’en mode visuel supprime cette couche d’abstraction et rend le comportement prévisible.
A lire en complément : Recherche utilisateur : comprendre le processus en profondeur
Pourquoi les builders ajoutent cette abstraction
Les page builders ciblent des utilisateurs qui ne manipulent pas directement les propriétés flex. Regrouper flex-grow, flex-shrink et flex-basis sous un seul bouton simplifie la prise en main, mais masque les effets de bord. En particulier, l’interaction entre flex-grow et la valeur implicite de flex-basis (souvent auto dans un builder, 0% dans le raccourci flex: 1) produit des résultats très différents.
Calcul de flex-grow : distribution de l’espace restant en CSS
flex-grow ne définit pas la taille finale d’un élément. Il définit la part d’espace restant que cet élément absorbe une fois que chaque item a occupé sa flex-basis.
Prenons un conteneur de 900 px avec trois enfants dont la flex-basis vaut 100 px chacun. L’espace restant est de 600 px. Si le premier enfant porte flex-grow: 2 et les deux autres flex-grow: 1, la somme des facteurs est 4. Le premier reçoit 300 px supplémentaires (2/4 de 600), les deux autres 150 px chacun.
Nous recommandons de toujours raisonner en deux temps : d’abord la base, ensuite la distribution. Sauter cette étape est la source principale d’erreurs dans les layouts flex.
Le raccourci flex et ses valeurs par défaut
Déclarer flex-grow: 1 seul laisse flex-shrink et flex-basis à leurs valeurs par défaut (1 et auto respectivement). Utiliser plutôt la propriété raccourcie flex: 1 pose flex-grow: 1, flex-shrink: 1 et flex-basis à 0%, ce qui change radicalement le comportement.
Avec flex-basis: auto, la taille intrinsèque du contenu compte dans le calcul. Avec flex-basis: 0%, tout l’espace du conteneur est redistribué proportionnellement. La différence est visible dès qu’un item contient plus de texte que les autres : en auto, il reste plus large, en 0%, les largeurs sont strictement proportionnelles aux facteurs flex-grow.
flex-grow: 1isolé conserveflex-basis: auto, les items ne sont pas égaux si leur contenu diffère.flex: 1(raccourci) forceflex-basis: 0%, l’espace total est partagé selon les ratios de grow.flex: 1 1 autocombine croissance et rétrécissement tout en respectant la taille intrinsèque du contenu.
Débordements liés à min-width auto et flex-grow
min-width: auto est le piège le plus fréquent sur les layouts qui utilisent flex-grow. Dès qu’un conteneur passe en display: flex, chaque enfant reçoit implicitement min-width: auto. L’item ne peut alors pas se réduire en dessous de la taille de son contenu, même avec flex-shrink: 1.
Le résultat : un bloc avec beaucoup de texte ou une image non contrainte « explose » la largeur du conteneur, provoquant une scrollbar horizontale. Ce comportement surprend particulièrement les utilisateurs de page builders qui activent Flex Extend sans comprendre pourquoi leur colonne déborde.
Correction pratique du débordement flex
La solution documentée consiste à poser min-width: 0 sur les items dotés d’un flex-grow. En direction colonne, c’est min-height: 0 qui s’applique. Cette déclaration autorise le navigateur à réduire l’item sous la taille de son contenu, restaurant le comportement attendu de flex-shrink.
Nous ajoutons systématiquement cette règle dans nos reset CSS pour les conteneurs flex. Sans elle, tout layout reposant sur flex-grow reste fragile face à du contenu dynamique.
Flex-grow ou CSS Grid : quand choisir chaque modèle de layout
Flexbox distribue l’espace sur un seul axe. flex-grow excelle pour les barres de navigation, les groupes de boutons, les zones de contenu principal flanquées d’une sidebar. Dès que le layout implique un alignement sur deux axes simultanés (lignes et colonnes), Grid devient plus lisible et plus prévisible.
Un cas courant : trois cartes de même hauteur et même largeur. Avec flex: 1, les cartes se répartissent bien sur une ligne, mais le passage à deux lignes (via flex-wrap: wrap) complique le contrôle de la dernière rangée. En Grid, grid-template-columns: repeat(3, 1fr) gère nativement ce scénario sans calcul de grow.
- Utiliser
flex-growpour la distribution d’espace sur un axe unique avec des items de taille variable. - Préférer Grid quand le layout repose sur une grille bidimensionnelle ou quand le nombre de colonnes est fixe.
- Combiner les deux : un Grid global pour la macro-structure, du flex avec
flex-growà l’intérieur de chaque cellule pour la micro-distribution.
flex-grow complète Grid, il ne le remplace pas. Choisir l’un ou l’autre dépend de l’axe de distribution, pas d’une préférence personnelle.
La prochaine fois qu’un page builder propose d’activer Flex Extend, ouvrez l’inspecteur. Vérifiez la valeur de flex-basis générée et ajoutez min-width: 0 si le contenu est dynamique. Ces deux réflexes évitent la majorité des bugs de layout liés à flex-grow.
