Structurer un projet avec les Container Queries

Les Container Queries révolutionnent la manière dont nous pensons le responsive design en CSS. Contrairement aux media queries classiques qui se basent sur la taille de la fenêtre, les container queries permettent de styler des composants en fonction de la taille de leur conteneur parent. Cette approche change radicalement la conception modulaire et réutilisable des interfaces.

Dans cet article, nous explorons comment structurer efficacement un projet utilisant les container queries, du setup initial jusqu'aux bonnes pratiques de maintenance. Vous découvrirez comment organiser votre CSS, gérer les dépendances entre conteneurs et éviter les pièges courants qui ralentissent les performances.

Comprendre les Container Queries et leur syntaxe

Les container queries permettent de conditionner le CSS basé sur la largeur (ou hauteur) d'un élément conteneur spécifique. La première étape consiste à déclarer un conteneur contextuel avec container-type.

Dans cet exemple, container-type: inline-size crée un conteneur sensible à la largeur disponible. Les règles @container s'appliquent uniquement quand les conditions de taille sont remplies. C'est particulièrement utile pour les composants réutilisables qui s'adaptent à différents contextes sans modifier le HTML.

La syntaxe container-name permet de cibler un conteneur spécifique si plusieurs niveaux de conteneurs existent. Sans nom, les queries ciblent le plus proche conteneur contextuel.

Organiser l'architecture CSS pour les container queries

Une bonne structure est essentielle pour maintenir un projet container queries. Voici une organisation recommandée :

Séparez les déclarations de conteneurs des styles des composants. Créez un fichier CSS dédié pour chaque conteneur majeur. Cette séparation facilite le debugging et les modifications futures.

Dans containers/card-container.css :

Puis dans components/card.css :

Cette approche maintient une séparation claire des responsabilités. Les conteneurs définissent le contexte, les composants s'adaptent au contexte. Les tests et maintenances deviennent plus simples.

Gérer les points de rupture et les cas limites

Définissez des points de rupture cohérents adaptés à vos composants réels, pas à des appareils génériques. Documentez-les centralement :

Un piège courant : les nested containers. Si un conteneur se trouve à l'intérieur d'un autre conteneur, la query s'applique au conteneur le plus proche. Testez vos composants dans différents contextes pour éviter les surprises.

Utilisez aussi container: size pour les deux axes (largeur et hauteur) si nécessaire, mais c'est plus gourmand en performances. Préférez inline-size en général :

Bonnes pratiques et performance

Plusieurs principes optimisent vos container queries :

1. Nommez explicitement vos conteneurs. Évitez les dépendances implicites sur le premier conteneur contextuel. Un nom explicite rend le code plus lisible et maintenable.

2. Limitez la profondeur des conteneurs. Chaque conteneur a un coût en performance. Créez des conteneurs uniquement pour les composants majeurs nécessitant l'adaptation.

3. Testez sur des appareils réels. Les simulations ne révèlent pas toujours les problèmes de rendu. Testez sur mobile, tablette et desktop avec redimensionnement de fenêtre.

4. Utilisez des custom properties pour la flexibilité :

5. Fallback pour la compatibilité navigateur. Les container queries sont relativement récentes. Proposez des fallbacks pour les anciens navigateurs :

Exemple complet : composant de liste adaptative

Voici un exemple pratique complet :

HTML:     Titre

Description courte

Voir plus

Ce composant s'adapte automatiquement selon l'espace disponible, peu importe le contexte où il est inséré.

Les container queries transforment la réutilisabilité des composants. Structurez votre projet dès le départ avec une séparation claire entre conteneurs et composants. Testez régulièrement sur plusieurs résolutions et gardez vos CSS modulaires. Cette approche scalable épargne du refactoring futur et facilite grandement la maintenance. Commencez aujourd'hui en appliquant ces principes à vos nouveaux composants, puis migrez progressivement votre codebase existante.