Une carte de produit affichée dans une colonne latérale étroite et la même carte affichée en pleine largeur devraient probablement ne pas se ressembler : l'une gagnerait à empiler son image et son texte, l'autre à les mettre côte à côte. Une Media query ne peut pas faire cette distinction, puisqu'elle ne connaît que la largeur de l'écran entier, pas celle du bloc où la carte se trouve réellement.
La container query a été conçue précisément pour ce cas : elle réagit à la taille du parent direct du composant, pas à celle de la fenêtre.
Définition
Une container query est une règle @container qui applique un bloc de CSS selon la largeur, ou parfois la hauteur, d'un ancêtre déclaré comme conteneur. Elle permet à un composant de changer d'apparence selon l'espace qui lui est réellement alloué, indépendamment de la taille de l'écran qui affiche la page.
Syntaxe
Deux étapes sont nécessaires. D'abord, l'élément parent doit être déclaré comme conteneur avec container-type. Ensuite, la règle @container cible ce conteneur et applique son CSS quand la condition de largeur est remplie.
.zone-carte {
container-type: inline-size;
container-name: carte;
}
.carte {
display: flex;
flex-direction: column;
}
@container carte (min-width: 400px) {
.carte {
flex-direction: row;
gap: 16px;
}
}Sans la ligne container-type: inline-size, la règle @container qui suit ne se déclenche jamais : c'est l'erreur la plus fréquente en découvrant cette fonctionnalité.
Media query contre container query
Les deux se ressemblent dans leur syntaxe, mais elles ne répondent pas à la même question.
| Media query | Container query |
|---|---|
| Réagit à la largeur de la fenêtre entière | Réagit à la largeur du bloc parent |
| Un même composant se comporte pareil partout sur la page | Un même composant s'adapte à son emplacement |
| Aucune déclaration préalable requise | Le parent doit être déclaré container-type |
Le piège classique
Oublier de déclarer le conteneur n'est pas la seule embûche : un élément ne peut pas être son propre conteneur pour ses propres enfants tout en réagissant à une container query définie sur lui-même. Il faut un ancêtre distinct qui porte container-type, et l'élément stylé par @container se trouve à l'intérieur de cet ancêtre, jamais confondu avec lui.
container-type est posé sur le parent avant de chercher pourquoi une règle @container ne se déclenche pas. C'est l'oubli le plus courant, et il ne produit aucune erreur visible dans la console, la règle est simplement ignorée en silence.Cas d'usage typique
Le cas le plus cité reste le composant réutilisable placé dans plusieurs contextes d'une même interface : une carte affichée à la fois dans une grille de résultats et dans une barre latérale de suggestions, ou un composant de Flexbox qui doit s'empiler dans un espace étroit. Le composant lui-même n'a besoin que d'une seule définition CSS, sensible à l'espace qu'on lui accorde, plutôt que d'une variante distincte par contexte d'usage.
Une bibliothèque de composants partagée entre plusieurs projets profite particulièrement de cette approche : chaque composant devient responsable de sa propre adaptation, sans jamais imposer à la page qui l'utilise de connaître à l'avance dans quel contexte il sera placé.
Questions fréquentes
Non. Certaines décisions, comme changer de police par défaut selon l'orientation de l'écran ou détecter le mode sombre du système, dépendent réellement de l'appareil et restent du ressort de la media query. La container query s'ajoute pour les cas où c'est l'espace du composant, pas celui de l'écran, qui doit décider.
Oui, un composant peut réagir à son conteneur direct pendant que ce conteneur réagit lui-même à un conteneur plus large, à condition que chaque niveau porte son propre container-name pour que la bonne règle cible le bon élément sans ambiguïté.
Le principe est identique : le seuil choisi dans min-width doit correspondre au moment où le composant devient inconfortable dans son conteneur, constaté en rétrécissant le parent, pas une valeur arbitraire recopiée d'un autre projet.