Le problème historique des media queries
Depuis leur introduction, les media queries ont un défaut fondamental : elles répondent à la taille de la fenêtre du navigateur, pas à la taille du conteneur qui affiche un composant. Un composant "carte" dans une sidebar étroite et le même composant en pleine largeur devaient donc être gérés par des règles globales fragiles.
❌ Avant — Media query globale
Le composant dépend de la largeur du viewport. Impossible de le réutiliser dans des contextes différents sans casser le layout.
✅ Après — Container query
Le composant s'adapte à son propre conteneur. On peut l'utiliser dans une sidebar, un modal, ou en pleine largeur — il se débrouille.
La syntaxe en pratique
L'implémentation est simple : on déclare un contexte de conteneur sur l'élément parent, puis on écrit des règles qui réagissent à sa taille.
.card-wrapper {
container-type: inline-size;
container-name: card;
}
/* 2. Adapter le composant à son conteneur */
@container card (min-width: 400px) {
.card {
display: grid;
grid-template-columns: 200px 1fr;
}
}
/* 3. Utiliser les unités de conteneur */
.card-title {
font-size: clamp(1rem, 4cqi, 2rem);
/* cqi = 1% de la inline-size du conteneur */
}
L'unité cqi : le clamp du futur
Les container queries introduisent de nouvelles unités : cqi (1% de la largeur du conteneur), cqb (hauteur), cqmin, cqmax. Combinées avec clamp(), elles permettent une typographie fluide qui répond au conteneur plutôt qu'au viewport. C'est ce que fait TYPESET sur ses cards.
« Les container queries font pour les composants ce que les media queries ont fait pour les layouts. Elles rendent le CSS enfin composable. »
Support et adoption en 2025
Le support est désormais universel dans les navigateurs modernes. Les grands frameworks — Tailwind, Bootstrap, et les design systems d'entreprise — ont intégré les container queries dans leurs dernières versions. Ce n'est plus une fonctionnalité expérimentale : c'est la pratique standard pour tout nouveau composant.