Les composants réutilisables en CSS reposent souvent sur une combinaison de flex-grow, flex-shrink et flex-basis pour gérer leur mise en page interne. Le problème survient quand ces composants changent de contexte : une carte conçue pour une sidebar ne se comporte pas de la même façon dans une grille pleine largeur. La propriété flex seule ne suffit pas à garantir l’extensibilité d’un composant d’un projet à l’autre ou d’un conteneur à l’autre.
L’arrivée des container queries dans les navigateurs modifie la donne. Elle permet de conditionner le comportement flex d’un élément non plus au viewport, mais à son conteneur direct, ce qui change la manière de concevoir des composants réutilisables.
Container queries et flex : pourquoi le viewport ne suffit plus pour les composants
Les tutoriels classiques sur flexbox partent d’un postulat implicite : le composant vit dans un contexte connu. On définit flex-direction, flex-wrap et les proportions des éléments en fonction d’une largeur de page prévisible. Les media queries ajustent le tout selon le viewport.
Cette approche fonctionne pour une page construite en bloc, mais elle se dégrade dès qu’un même composant est inséré dans des conteneurs de tailles différentes. Un widget flex pensé pour 800 px de large, placé dans une colonne latérale de 300 px, ne peut pas se reconfigurer via une media query. Le viewport n’a pas changé, seul le conteneur a rétréci.
Les container queries résolvent ce décalage en ciblant le conteneur parent. En déclarant container-type sur l’élément parent, puis en utilisant la règle @container, le composant adapte sa mise en page flex selon l’espace réellement disponible autour de lui, pas selon la fenêtre du navigateur.
Concrètement, un composant carte peut passer d’un affichage flex-direction: row (image à gauche, texte à droite) à flex-direction: column (image au-dessus, texte en dessous) quand son conteneur passe sous un certain seuil de largeur. Le composant devient autonome.
Flex extend dans un design system : structurer l’extensibilité avec container-type
L’expression « flex extend » désigne une approche où le comportement flexible d’un composant est conçu pour être étendu ou modifié sans réécrire ses styles de base. Dans un design system, cela suppose de séparer deux couches : la structure flex interne du composant et les conditions d’adaptation liées au contexte.
Séparer la structure flex de la logique d’adaptation
La structure interne (display: flex, gap, align-items) reste stable. Elle définit comment les éléments enfants se positionnent les uns par rapport aux autres. La logique d’adaptation, elle, est déléguée aux container queries.
- Le composant déclare ses propriétés flex de base sans media query : flex-wrap, gap, align-items, et éventuellement flex-basis sur les enfants.
- Le conteneur parent porte la déclaration container-type: inline-size, signalant au navigateur qu’il doit mesurer la largeur disponible.
- Les blocs @container, placés dans la feuille de styles du composant, modifient flex-direction, flex-wrap ou les proportions flex-grow/flex-shrink selon la taille du conteneur.
Cette séparation garantit que le composant reste fonctionnel même sans container query (mode dégradé) tout en s’adaptant quand le navigateur le permet.
Container query units pour des tailles internes cohérentes
Les unités spécifiques aux container queries (cqi, cqb, cqmin, cqmax) permettent d’exprimer les dimensions internes d’un composant en proportion de son conteneur. Au lieu de fixer un padding en rem ou un flex-basis en pourcentage du viewport, les unités cqi expriment les tailles relativement au conteneur direct.
Un flex-basis défini en cqi s’ajuste automatiquement quand le composant est déplacé dans un conteneur plus étroit ou plus large. Les retours terrain divergent sur ce point : certaines équipes trouvent ces unités trop peu lisibles pour être adoptées à grande échelle, d’autres les considèrent comme le complément naturel de flex-basis dans un composant réutilisable.
Style queries et propriétés custom : étendre le comportement flex sans modifier le CSS du composant
Les container queries ne se limitent pas à la taille. Les style queries, classées en Baseline 2024, permettent de conditionner les styles d’un composant à la valeur d’une propriété CSS custom définie sur son conteneur.
L’intérêt pour l’extensibilité flex est direct. Un composant peut lire une variable comme –layout-mode sur son parent et ajuster son flex-direction, son gap ou ses proportions en conséquence, sans qu’aucune classe modificatrice ne soit ajoutée au HTML.
Les style queries transforment les propriétés custom en API déclarative du composant. Le consommateur du composant modifie une variable CSS sur le conteneur, le composant s’adapte. Le code HTML ne bouge pas, le CSS interne du composant reste fermé à la modification, ouvert à l’extension.
Les données disponibles ne permettent pas encore de conclure sur l’adoption réelle des style queries en production. Le support navigateur est récent, et la majorité des design systems n’ont pas encore intégré ce mécanisme. En revanche, le principe « flex extend » via propriétés custom fonctionne déjà sans style queries : on peut utiliser des variables CSS comme flex-direction: var(–card-direction, row) et les surcharger sur le conteneur.
Pièges courants quand on combine flexbox et container queries dans des composants réutilisables
Combiner flex et container queries dans un composant réutilisable introduit des contraintes que les guides Flexbox standards ne mentionnent pas.
Un conteneur flex ne peut pas être simultanément un conteneur de requête de taille. Si un élément porte display: flex et container-type: inline-size, le calcul de sa largeur intrinsèque peut produire des résultats inattendus, car container-type: inline-size impose un containment de taille en ligne. En pratique, il faut souvent ajouter un élément wrapper dédié au containment, distinct du conteneur flex.
Autre point : flex-basis interagit avec le containment de manière non intuitive. Un élément enfant avec flex-basis: auto dans un conteneur qui a un containment de taille peut ne pas se dimensionner comme prévu, car le navigateur ne peut plus remonter la chaîne de dimensionnement intrinsèque.
- Tester systématiquement le composant dans au moins trois largeurs de conteneur différentes, pas seulement les breakpoints habituels.
- Éviter de placer container-type directement sur l’élément qui porte display: flex. Préférer un wrapper parent.
- Documenter les propriétés custom attendues par le composant (–card-direction, –card-gap) comme une API, avec valeurs par défaut explicites via la syntaxe var(–prop, fallback).
L’extensibilité d’un composant flex se joue moins dans le CSS écrit que dans le CSS anticipé. Un composant qui expose ses axes de variation via des propriétés custom et des container queries reste réutilisable sans fork. Un composant qui encode ses breakpoints en media queries et ses variantes en classes BEM finit dupliqué à chaque nouveau contexte d’insertion.
La combinaison flex et container queries est encore jeune. Les conventions de nommage, la granularité des containers et la gestion du fallback pour les navigateurs plus anciens restent des sujets ouverts. Concevoir l’extensibilité dès le départ, plutôt que de la greffer après coup, reste la seule approche qui évite la dette technique sur ce type de composants.
