Un badge de promotion produit affiché en pleine largeur sur une fiche produit devient illisible une fois recopié tel quel dans une grille catalogue à quatre colonnes, ou pire, dans le mini-panier réduit à moins de deux cents pixels. La solution la plus courante, empiler des media queries ciblant chaque emplacement, tient rarement plus de quelques mois avant qu’un nouveau gabarit ne vienne tout casser.
La raison est simple à énoncer une fois qu’on l’a identifiée : une media query réagit à la largeur de la fenêtre du navigateur, pas à celle du conteneur réel dans lequel le badge est affiché. Un badge peut donc se trouver dans un conteneur étroit sur un grand écran, par exemple dans une colonne latérale, sans qu’aucune media query classique ne le sache.
Ce que changent réellement les container queries
Les container queries CSS, via la règle @container, réagissent à la largeur (ou à la hauteur) du conteneur parent défini explicitement, indépendamment de la taille de la fenêtre. Il suffit de déclarer ce conteneur avec la propriété container-type, puis d’écrire des règles conditionnelles qui s’appliquent uniquement à l’intérieur de ce contexte.
.badge-promo-conteneur {
container-type: inline-size;
container-name: badge-promo;
}
.badge-promo {
font-size: 0.9rem;
padding: 0.4rem 0.6rem;
}
@container badge-promo (max-width: 200px) {
.badge-promo {
font-size: 0.7rem;
padding: 0.2rem 0.4rem;
}
}
@container badge-promo (min-width: 400px) {
.badge-promo {
font-size: 1.1rem;
padding: 0.6rem 1rem;
}
}
Un seul composant, trois emplacements
Le badge de promotion, dans ce projet, s’affiche à trois endroits distincts d’une même boutique WooCommerce : sur la fiche produit en pleine largeur, dans chaque carte de la grille catalogue, et dans le mini-panier ouvert en superposition. Avant le passage aux container queries, trois classes CSS distinctes existaient pour ce même composant, une par emplacement, avec des valeurs dupliquées et déjà légèrement désynchronisées entre elles.
Avec container-type: inline-size posé sur le conteneur direct de chaque emplacement, le badge lui-même n’a plus qu’un seul jeu de règles à maintenir :
- Dans la grille catalogue, chaque carte produit devient elle-même le conteneur nommé, ce qui adapte le badge à la largeur réelle de la colonne, variable selon le nombre de colonnes affichées.
- Dans le mini-panier, le conteneur correspond à la largeur du panneau glissant, généralement plus étroit qu’une carte de grille.
- Sur la fiche produit, le conteneur correspond à la zone d’affichage du prix, plus large que les deux autres cas.
Le piège de container-type sur le mauvais élément
Une erreur fréquente consiste à poser container-type directement sur l’élément du badge plutôt que sur son parent : un élément déclaré comme conteneur ne peut pas, par construction, interroger sa propre taille dans une @container qui le cible lui-même. Le conteneur doit toujours être un ancêtre de l’élément stylé par la règle conditionnelle.
Nommer ses conteneurs plutôt que les laisser anonymes
Sur un thème qui empile plusieurs niveaux de conteneurs imbriqués, une règle @container sans nom cible le conteneur le plus proche, ce qui devient vite ambigu. Nommer explicitement chaque conteneur avec container-name, comme dans l’exemple ci-dessus, évite qu’une règle destinée au badge n’interfère accidentellement avec un autre composant partageant la même hiérarchie de conteneurs.
Je recommande de nommer systématiquement les conteneurs dès qu’un composant est réutilisé à plus de deux emplacements différents : le gain de lisibilité, au moment de reprendre le code six mois plus tard, dépasse largement l’effort de nommage initial.
Ce que les container queries ne remplacent pas
La mise en page générale de la grille produit, avec son nombre de colonnes selon la largeur de l’écran, continue de relever des media queries classiques ou d’une grille CSS fondée sur auto-fit et minmax(). Les container queries interviennent à un niveau plus local : l’adaptation d’un composant à l’espace réellement disponible autour de lui, une fois la mise en page générale déjà déterminée.
Notre verdict
Pour un composant réutilisé dans des contextes de largeur variable comme un badge promotionnel, les container queries suppriment la duplication de règles et la désynchronisation qui l’accompagne presque toujours à terme. La contrainte principale reste de bien identifier, pour chaque emplacement, quel élément doit porter container-type, sous peine de règles conditionnelles qui ne se déclenchent jamais.
