CSS Container Queries : le responsive sans Media Query

Introduction aux Container Queries

Comprendre les Container Queries

Contrairement aux media queries (basées sur la fenêtre), les container queries adaptent les règles CSS selon les dimensions d'un conteneur parent. Elles sont particulièrement utiles pour des composants isolés dans des layouts flexibles (cards, widgets, modules réutilisables).

Les bénéfices pratiques : meilleure encapsulation des styles, composants plus autonomes, et réduction des règles globales qui complexifient la maintenance.

• Flexibilité accrue pour les composants
• Encapsulation des règles CSS au niveau du composant
• Réduction des media queries globales
• Comportement prévisible dans des mises en page imbriquées

Exemple minimal :

@container (min-width: 500px) {
  .button {
    padding: 20px;
    font-size: 1.5em;
  }
}

Le bloc ci-dessus applique le style à .button quand le conteneur parent atteint 500px de largeur.

Différences entre Media Queries et Container Queries

Comparaison des Approches

Media queries : règles dépendant du viewport (@media). Container queries : règles dépendant du parent (@container), ce qui permet à un même composant d'avoir un comportement différent selon l'espace qui lui est alloué dans la page.

• Media Queries : adaptées aux changements globaux du viewport
• Container Queries : adaptées au contexte local du composant
• Meilleure modularité et réutilisabilité avec les container queries

Exemple de media query :

@media (max-width: 600px) {
  .container {
    display: flex;
  }
}

Comparaison visuelle : Viewport vs Conteneur

Le schéma ci-dessous illustre la différence : à gauche, une modification basée sur le viewport affecte tout le layout ; à droite, une modification basée sur le conteneur ne change que le composant et respecte son contexte.

Syntaxe et Utilisation des Container Queries

Comment les Utiliser

Commencez par déclarer un conteneur avec container-type et, si besoin, container-name. container-type précise l'axe à observer (size ou inline-size), tandis que container-name permet de nommer et cibler un conteneur particulier dans une hiérarchie.

Exemple avec container-name (pratique pour les bibliothèques de composants) :

<div class="cards">
  <article class="card">Contenu 1</article>
  <article class="card">Contenu 2</article>
</div>

.cards {
  container-type: inline-size;
  container-name: cards;
  display: grid;
  gap: 1rem;
}

.card {
  padding: 1rem;
  border: 1px solid #e2e8f0;
}

@container cards (min-width: 600px) {
  .cards {
    grid-template-columns: repeat(2, 1fr);
  }
}

Dans l'exemple ci‑dessus, la règle @container cards (min-width: 600px) s'applique uniquement au conteneur nommé cards et à son contenu.

Shorthand pratique : il est possible d'utiliser la propriété raccourcie container pour définir nom et type sur une même ligne. Exemple :

.cards {
  /* shorthand : container <name> / <type> */
  container: cards / inline-size;
  display: grid;
  gap: 1rem;
}

• Définir le conteneur avec container-type (ou la shorthand container).
• Écrire des règles @container ciblées.
• Utiliser des noms pour résoudre les conflits dans les hiérarchies imbriquées.

Unités de conteneur (cqw, cqh, cqi, cqb, cqmin, cqmax)

Les unités de conteneur permettent de dimensionner des propriétés (typo, marges, tailles) en proportion de la boîte de conteneur plutôt qu'en pourcentage du parent direct. Les principales unités :

• cqw — 1% de la largeur du conteneur (container width)
• cqh — 1% de la hauteur du conteneur (container height)
• cqi — 1% de la dimension de l'axe inline du conteneur (dépend du writing-mode)
• cqb — 1% de la dimension de l'axe block du conteneur
• cqmin / cqmax — respectivement la plus petite et la plus grande dimension entre inline & block (utile pour s'adapter selon l'orientation du conteneur)

Exemples d'utilisation pratiques — typographie fluide à l'intérieur d'un composant :

.card {
  /* taille de base */
  font-size: 1rem;
}

@container (min-width: 40cqw) {
  /* lorsque le conteneur a une largeur suffisante, augmenter la typo proportionnellement */
  .card {
    font-size: clamp(1rem, 2cqw, 1.25rem);
  }
}

@container (min-width: 50cqh) {
  /* exemple alternatif utilisant la hauteur du conteneur */
  .card--tall {
    font-size: clamp(1rem, 1.8cqh, 1.3rem);
  }
}

Bonnes pratiques :

• Utilisez clamp() pour éviter des variations typographiques extrêmes.
• Privilégiez les unités cqw pour régler la mise en page horizontale et cqh pour les composants nécessitant une adaptation verticale.
• Testez le rendu dans des conteneurs de tailles variées (sidebars, modales, cards dans un grid) pour valider la lisibilité.

Cas Pratiques : Quand Utiliser les Container Queries

Utilisation dans les Projets Réels

Exemples concrets :

• E-commerce : cards produits qui doivent s'adapter au composant carte (incluses dans des sidebars, carrousels, grids).
• Dashboards : graphiques et widgets qui changent de type/arrangement selon l'espace disponible dans leur panneau.
• Bibliothèques de composants : boutons, badges, inputs qui s'ajustent automatiquement selon le conteneur parent.

Exemple simple pour deux colonnes sur un composant produit :

@container (min-width: 400px) {
  .product-card {
    grid-template-columns: repeat(2, 1fr);
  }
}

Fallback (CSS Grid) pour anciens navigateurs

Pour les navigateurs qui ne supportent pas encore les container queries, vous pouvez fournir un fallback partiel avec des media queries et le CSS Grid. Cette approche n'est pas aussi précise (elle dépend du viewport), mais elle garantit une présentation acceptable.

Stratégie recommandée :

1. Détecter le support via @supports.
2. Si non supporté, utiliser des media queries pour ajuster la grille (par ex. 1 colonne / 2 colonnes).

Exemple complet (CSS) :

/* Si le navigateur supporte container-type, utiliser container queries */
@supports (container-type: inline-size) {
  .cards {
    container: cards / inline-size;
    display: grid;
    gap: 1rem;
    grid-template-columns: 1fr;
  }

  @container cards (min-width: 600px) {
    .cards {
      grid-template-columns: repeat(2, 1fr);
    }
  }
}

/* Fallback pour navigateurs plus anciens : media queries basées sur le viewport */
@supports not (container-type: inline-size) {
  .cards {
    display: grid;
    gap: 1rem;
    grid-template-columns: 1fr;
  }

  /* Ajustement simple via viewport : couvre la majorité des cas */
  @media (min-width: 800px) {
    .cards {
      grid-template-columns: repeat(2, 1fr);
    }
  }
}

Remarques :

• Le fallback n'atteint pas la granularité d'une vraie container query (par ex. une card dans une sidebar étroite), mais il améliore l'affichage pour la majorité des utilisateurs d'anciens navigateurs.
• Pour des composants critiques, envisagez un petit script JS qui mesure la largeur effective du conteneur et ajoute une classe utilitaire (approche plus coûteuse en JS).

Avantages et Limitations des Container Queries

Évaluer les Bénéfices

Les container queries offrent :

• Encapsulation et réutilisabilité des composants.
• Moins de règles globales et de duplications CSS.
• Comportement plus prévisible dans des layouts complexes.

Compatibilité navigateurs (mise à jour)

Support stable : Chrome (depuis la version 105, août 2022), Safari (depuis la version 16) et Firefox (depuis la version 110) ont un support solide des container queries. Vérifiez régulièrement l'état sur Can I Use avant un déploiement large.

Prudence et bonnes pratiques

• Testez sur plusieurs navigateurs et environnements.
• Utilisez container-name pour éviter les collisions dans des layouts imbriqués.
• Évitez d'empiler trop de règles conditionnelles qui pourraient conduire à des reflows coûteux à chaque redimensionnement du conteneur.

Pour un déploiement progressif, combinez @supports et des fallbacks CSS/JS :

@supports (container-type: inline-size) {
  /* utilisation des container queries */
}
@supports not (container-type: inline-size) {
  /* fallback : media queries ou JS pour mesurer et appliquer des classes */
}

Style Queries (perspective d'évolution)

Au-delà des container queries, la communauté travaille sur des évolutions comme les "Style Queries" (permettant d'évaluer des conditions plus riches ou d'appliquer des règles de style déclaratives dépendant d'états). Le support est encore limité et il s'agit d'une perspective d'évolution du langage CSS plutôt qu'une fonctionnalité universelle aujourd'hui.

Que faire aujourd'hui ? Surveillez les spécifications publiées par le W3C et les ressources officielles (MDN, Can I Use) ; planifiez l'adoption progressive et préférez des patterns qui facilitent une migration future (noms de conteneurs clairs, composants isolés, tests automatisés visuels).

L'avenir du Responsive Design avec les Container Queries

Une approche novatrice pour le design adaptatif

Les container queries rendent possible la conception d'interfaces composables : chaque composant devient responsable de son propre rendu selon l'espace qui lui est réservé. Dans les systèmes de design et les frameworks modernes (React, Vue), cela simplifie la distribution de composants réutilisables sans multiplier les props CSS.

Cas réel : lors d'une refonte de dashboard, l'introduction des container queries a réduit la duplication CSS et simplifié le comportement responsive des widgets. Pour l'adoption progressive, combinez @supports et des fallbacks CSS/JS.

Problèmes courants et dépannage

• Problème : les règles @container ne s'appliquent pas → Vérifier que le parent a bien container-type (et que le nom, si utilisé, correspond à container-name).
• Problème : comportement différent entre navigateurs → Tester sur les versions indiquées (Chrome ≥105, Safari ≥16, Firefox ≥110).
• Astuce de debug : utiliser les outils DevTools (Inspector) pour voir si un élément est reconnu comme conteneur et quelles règles @container s'appliquent.
• Performance : limiter le nombre d'observations de conteneur sur des éléments très nombreux et préférer des regroupements lorsque possible.