CSS Container Queries : ne les utilisez plus comme des media queries
Le plus gros malentendu CSS de 2026
En février 2023, les CSS Container Queries arrivaient enfin dans tous les navigateurs majeurs : Chrome 105, Edge 105 et Safari 16 les avaient livrées dès l'automne 2022, Firefox 110 a fermé la marche. En 2026, elles affichent 94% de support et sont passées Baseline « Widely available » en août 2025 — le palier à partir duquel on peut les poser sans filet.
Pourtant, le State of CSS 2025 raconte une histoire gênante : 86% des développeurs connaissent la fonctionnalité, mais seulement 41,4% l'utilisent.
Kevin Powell le résumait parfaitement à SmashingConf Amsterdam 2026 : "Container Queries adoption has been terrible."
Le problème ? Pas la connaissance. La compréhension. Parce que @container ressemble furieusement à @media, on les utilise pareil. C'est une erreur.
Le constat de départ et plusieurs des exemples qui suivent viennent de « Stop Treating CSS Container Queries Like Traditional Media Queries », publié par Victor Ayomipo sur Smashing Magazine le 16 septembre 2026.
Media queries regardent dehors, container queries regardent dedans
Quand vous écrivez @media (min-width: 1024px), vous demandez au navigateur : "Combien mesure l'écran ?"
C'est utile pour la structure de page. Mais qu'arrive-t-il à votre carte .card quand elle est placée dans une grille de 300px de large sur un écran 1920px ?
La media query s'en fiche. Pour elle, l'écran fait toujours 1920px. Les styles "desktop" s'appliquent, et votre carte déborde ou s'écrase.
/* Media query : regarde le viewport */
@media (min-width: 1024px) {
.card {
display: flex;
}
}
La container query, elle, demande : "Combien d'espace mon parent me donne-t-il, là, maintenant ?"
/* Déclarer le conteneur */
.card-wrapper {
container-type: inline-size;
}
/* Container query : regarde le parent */
@container (min-width: 450px) {
.card {
display: flex;
flex-direction: row;
}
}
La carte passe en horizontal quand son conteneur atteint 450px — pas quand l'écran dépasse 1024px. C'est plus précis, plus résilient, et ça marche dans une sidebar comme en plein écran.
Macro-layout vs micro-layout
La distinction est simple :
| Type | Outil | Scope | Exemples |
|---|---|---|---|
| Macro-layout | @media | Structure de page | Header, footer, grille principale, prefers-color-scheme |
| Micro-layout | @container | Composants réutilisables | Cartes, formulaires, widgets, navigation, listes |
Règle : Un composant utilisé dans plus d'un contexte → container query. Un élément qui existe uniquement au niveau page → media query.
Le saviez-vous ? Il y a plus de 2 300 tailles de viewport uniques sur le web moderne. Essayer de toutes les couvrir avec des media queries est une illusion. Les container queries rendent vos composants intrinsèquement adaptatifs — ils s'ajustent à la taille réelle qu'on leur donne.
Exemple concret : typo fluide dans un composant
Avec les media queries, on utilise vw pour le typo responsive :
.card-title {
font-size: clamp(100%, 1rem + 2vw, 24px);
}
Ça marche... jusqu'à ce que la carte soit dans un sidebar. Là, 2vw sur un écran large donne un texte trop grand pour l'espace disponible.
Avec les container queries et leurs unités dédiées (cqi, cqw) :
.card-title {
font-size: clamp(1rem, 0.5rem + 3cqi, 2rem);
}
3cqi = 3% de la taille du conteneur, pas du viewport. Le texte s'adapte à l'espace réellement disponible. C'est la différence entre un design qui "marche en desktop" et un design qui marche partout.
Détection de wrap Flexbox sans JavaScript
Un cas où les container queries brillent : détecter quand des éléments flex wrap sur une nouvelle ligne.
/* Parent flex */
.flex-layout {
display: flex;
flex-wrap: wrap;
}
/* Chaque item est aussi un conteneur */
.flex-item {
container-type: inline-size;
flex: 1 1 390px;
}
/* État "wrap" : l'item a soudain plus de largeur */
@container (min-width: 600px) {
.card {
display: flex;
flex-direction: row;
}
}
Quand l'item est seul sur sa ligne (wrap), son conteneur s'élargit — la container query détecte ce changement et réorganise le layout. Impossible à faire avec une media query, qui ne "voit" que l'écran.
Les pièges à éviter
1. Déclarer le conteneur trop haut dans l'arbre DOM
Plus le conteneur est haut, plus il englobe d'enfants. Déclarez container-type sur le wrapper direct du composant que vous voulez adapter.
2. Utiliser size au lieu de inline-size
container-type: size applique la contrainte sur les deux axes (inline + block). Dans 90% des cas, inline-size suffit et évite des comportements de hauteur inattendus.
3. Noms de conteneur en conflit
Si vous utilisez container-name, assurez-vous que les noms sont uniques dans le scope. Sans nom, @container cible le conteneur ancêtre le plus proche — ce qui est souvent ce que vous voulez.
4. Variables CSS dans les container queries
Les @container ne peuvent pas utiliser de variables CSS personnalisées dans la condition de taille :
/* NE MARCHE PAS */
@container (min-width: var(--breakpoint)) {
.card { ... }
}
Utilisez des valeurs littérales dans les conditions de container query.
Quand les garder en production aujourd'hui
La checklist pour adopter les container queries dans votre prochain projet :
- Déclarez
container-type: inline-sizesur les wrappers de composants réutilisables - Remplacez les media queries des composants par des
@container - Utilisez
cqi/cqwpour le typo fluide dans les composants - Gardez
@mediapour la macro-structure (header, footer, grilles) - Ajoutez des styles fallback hors des blocs
@containerpour les vieux navigateurs - Testez avec le même composant dans deux contextes de largeur différente
Les container queries ne remplacent pas les media queries — elles les complètent. Mais les traiter comme des media queries revient à utiliser un scalpel comme un marteau. L'outil est différent, le problème est différent, et le résultat est bien meilleur quand on les utilise correctement.
