CSS Container Queries : un design responsive basé sur le conteneur, pas sur l'écran

Pendant des années, le design responsive en CSS s'est presque toujours appuyé sur la largeur de la fenêtre du navigateur, contrôlée via les media queries. Cette approche fonctionne bien pour la mise en page générale d'un site, mais montre ses limites dès qu'il s'agit de créer des composants réutilisables : une carte, un widget de barre latérale, tout élément qui doit s'adapter à l'espace qui lui est réellement alloué, et non à l'écran de l'utilisateur. Les CSS Container Queries répondent précisément à ce problème, et en 2026 il s'agit d'une technologie mature, prise en charge par tous les principaux navigateurs modernes.

Cet article explique ce qu'elles sont, comment les utiliser concrètement, et dans quels cas elles cohabitent avec les media queries plutôt que de les remplacer.

Que sont les container queries et pourquoi les utiliser

Une container query applique des règles CSS à un élément en fonction de la taille (ou du style) de son élément conteneur, et non du viewport. En pratique : placez la même carte dans une colonne large puis dans une barre latérale étroite, et elle peut automatiquement changer de mise en page, de taille de texte ou d'agencement selon l'espace réel disponible autour d'elle, indépendamment de la largeur totale de l'écran.

C'est ce qui rend possible un véritable design au niveau du composant : le même bloc HTML/CSS peut être réutilisé à différents endroits d'un site et se comportera intelligemment partout où il sera placé.

Activer un conteneur : container-type et container-name

Pour qu'un élément puisse être "interrogé" par ses enfants, il doit d'abord être déclaré comme conteneur de requête via la propriété container-type :

• inline-size : le cas le plus courant, permettant des requêtes basées uniquement sur la dimension en ligne du conteneur (généralement sa largeur).
• size : active les requêtes sur la largeur et la hauteur, mais exige que la hauteur du conteneur soit définie explicitement, sinon le contenu risque de s'effondrer.
• normal : valeur par défaut ; l'élément n'est pas un conteneur de requête de taille, mais peut tout de même être utilisé pour des requêtes basées uniquement sur le nom ou le style.

Un exemple minimal :

.post {
  container-type: inline-size;
}

Lorsqu'une page contient plusieurs conteneurs imbriqués, il est utile de les distinguer avec container-name, afin que les règles suivantes sachent à quel conteneur elles se réfèrent :

.post {
  container-type: inline-size;
  container-name: article;
}

Les deux propriétés peuvent aussi s'écrire sous forme abrégée avec la syntaxe container: nom / type;, par exemple container: article / inline-size;.

La syntaxe @container en pratique

Une fois le conteneur défini, les règles s'écrivent avec la règle at @container, dont la forme rappelle beaucoup @media :

@container (width > 700px) {
  .card h2 {
    font-size: 2em;
  }
}

Pour cibler un conteneur précis parmi plusieurs imbriqués, on ajoute son nom avant la condition :

@container article (width > 700px) {
  .card { font-size: 2em; }
}

Un cas concret fréquent est une carte qui empile titre et image lorsque l'espace est réduit (par exemple dans une barre latérale) et les place côte à côte lorsque le conteneur est plus large (par exemple dans la colonne centrale d'une page) : le même balisage HTML change de comportement automatiquement, sans classes supplémentaires ni JavaScript.

Les unités de longueur relatives au conteneur

Lorsqu'un élément est un conteneur de type size ou inline-size, des unités de longueur dédiées deviennent disponibles, conçues pour dimensionner polices, espacements ou éléments proportionnellement au conteneur plutôt qu'au viewport :

• cqw : 1 % de la largeur du conteneur.
• cqh : 1 % de la hauteur du conteneur.
• cqi : 1 % de la dimension en ligne du conteneur (généralement sa largeur, en écriture horizontale).
• cqb : 1 % de la dimension de bloc du conteneur (généralement sa hauteur).
• cqmin : la plus petite valeur entre cqi et cqb.
• cqmax : la plus grande valeur entre cqi et cqb.

Un exemple typique est un titre qui s'agrandit de façon fluide selon l'espace disponible, en combinant les unités cq avec clamp() ou max() :

.card h2 {
  font-size: max(1.5em, 1.23em + 2cqi);
}

Si un élément n'a pas de conteneur ancêtre valide, ces unités reviennent par sécurité aux unités équivalentes du viewport, évitant que la mise en page ne se casse.

Les container style queries : au-delà de la taille

Outre les requêtes de taille, la spécification introduit aussi les container style queries, qui permettent d'appliquer des règles en fonction du style du conteneur (par exemple la valeur d'une propriété personnalisée CSS), et non plus seulement de ses dimensions : @container style(--theme: sombre) { ... }. Il s'agit d'une fonctionnalité plus récente qui, contrairement aux requêtes de taille désormais stables partout, n'a encore qu'un support partiel : pleinement disponible sur Firefox, mais seulement partiellement sur Chrome, Edge et Safari. Pour une utilisation en production aujourd'hui, mieux vaut donc s'en tenir aux requêtes de taille et considérer les style queries comme une technique émergente à tester avec prudence.

Support des navigateurs en 2026

Les container queries basées sur la taille (via container-type: size ou inline-size) sont désormais considérées comme une technologie solide : prises en charge par Chrome et Edge depuis la version 106, par Safari depuis la version 16, et par Firefox depuis la version 110, ainsi que par leurs versions mobiles respectives (Safari sur iOS, Chrome pour Android, Samsung Internet, Firefox pour Android). Le support global dépasse aujourd'hui 94 % des utilisateurs, faisant défaut uniquement sur des navigateurs anciens ou de niche comme Internet Explorer, Opera Mini ou certains navigateurs Android régionaux (UC Browser, QQ Browser, Baidu Browser). Pour la plupart des projets web modernes, les container queries basées sur la taille peuvent donc être utilisées sans crainte particulière, en prévoyant éventuellement un repli via flexbox ou grid pour le public restant sur des navigateurs très anciens.

Container queries ou media queries : que choisir

Les deux techniques ne sont pas en concurrence, mais répondent à des besoins différents :

• Les media queries restent le bon choix pour la mise en page générale du site : nombre de colonnes, visibilité d'un menu, comportement de toute la grille selon le viewport.
• Les container queries sont le bon choix pour les composants individuels qui doivent être réutilisables et "conscients" de l'espace dans lequel ils sont placés : cartes, widgets, blocs d'un design system, éléments d'une barre latérale.

Dans des projets réels, les deux techniques cohabitent sans problème : les media queries définissent la structure générale de la page, tandis que les container queries affinent le comportement des composants qu'elle contient. Ce changement de perspective est particulièrement utile pour les équipes travaillant avec des design systems et des bibliothèques de composants, où le même bloc d'interface doit fonctionner correctement où qu'il soit placé.

Conclusion

Les CSS Container Queries comblent un manque historique du CSS responsive : la possibilité pour un composant de raisonner en fonction de son propre espace réel, et non seulement de la fenêtre du navigateur. Avec un support navigateur désormais solide pour les requêtes de taille, c'est le bon moment pour commencer à les introduire dans vos projets, en partant peut-être d'un seul composant (une carte, un encadré d'information) avant de généraliser l'approche à tout un design system. Les style queries, encore en phase d'adoption, sont à surveiller de près pour l'avenir proche.

Sources officielles

• MDN Web Docs – CSS container queries
• MDN Web Docs – Using container size and style queries
• Can I use – CSS Container Queries (Size)
• Can I use – CSS Container Style Queries