Les CSS Container Queries

C'est quoi les Container Queries ?

Il y a de grandes chances que tu te sois posé cette question en ouvrant cet article.

Il y a quelques jours, j'ai lancé un petit sondage sur Twitter et plus de 80% des personnes qui me suivent ne savent pas encore ce que c'est.

Si c'est aussi ton cas, rassure-toi c'est normal, c'est du CSS expérimental et pas un seul navigateur classique ne le supporte.

Mais c'est tellement puissant que ça vaut le coup de s'y intéresser dès maintenant. C'est le but de cet article, t'expliquer pourquoi c'est génial.

En lisant tu risques de passer par ces trois stades :

• C'est quoi ce truc ? 😐
• Mouais, ça pourrait être utile. 🤨
• Mais c'est trop bien en fait, je veux m'en servir tout de suite ! 😭

Pour commencer est-ce que tu connais les Media Queries en CSS ?

Oui ? Parfait.

Alors dis toi que les Container Queries c'est comme les Media Queries mais pour les containers.

Ok mais c'est quoi des "containers" exactement ?

Si tu préfères, on peut remplacer le mot "container" par "composant". Un composant ça peut être n'importe quel bloc de ton site Web :

• Des articles
• Une sidebar
• Ou encore une navigation

Mais c'est surtout intéressant pour les composants qui vont être utilisés à plusieurs endroits sur ton site.

Personnellement je n'ai pas été autant emballé par une nouveauté CSS depuis ma découverte des variables CSS, c'était il y a environ 4 ans donc ça ne date pas d'hier.

Ça sert à quoi ?

C'est simple, contrairement aux Media Queries qui permettent de changer l'apparence d'un élément en fonction de la taille du viewport (avec un media type à screen bien sûr), les Container Queries eux, vont permettre de changer l'apparence de tes éléments (encore une fois on peut dire "container", "composant", peu importe) en fonction de leur largeur !

Là tu peux te dire : "Mais c'est quoi l'intérêt, quand on change la taille du viewport, mécaniquement ça change aussi la largeur de mes composants.."

Je me suis dis la même chose au début, puis j'ai pris le temps de vraiment comprendre le fonctionnement des Container Queries, et maintenant je n'ai qu'une envie, que le support soit au rendez-vous.

Oui car avant d'aller plus loin il faut que tu saches qu'à l'heure actuelle les Container Queries font partie du module de spécification CSS Containment. On peut traduire ce module en Compartimentation CSS c'est peut-être plus clair.

Ce module est encore en "Working Draft", tu auras des infos sur le site du W3C avec une section dédiée aux Container Queries.

Si on prend le temps de regarder le support sur Can I Use, on voit qu'il n'est pas encore au rendez-vous :

Mais on peut quand même tester les Container Queries dès maintenant à condition d'installer une version un peu spéciale de Google Chrome. On verra cela un peu plus loin dans l'article. 🙂

Quel problème cela vient résoudre ?

Avant que je t'explique comment fonctionne les Container Queries, c'est important que tu comprennes quel problème cela vient résoudre.

Dans le schéma ci-dessus, on peut voir sur le premier écran que le container prend presque toute la largeur du viewport, tandis que sur le deuxième écran le container prend beaucoup moins de place.

J'ai fait ce schéma pour te monter qu'on ne pourrait pas changer l'apparence du container en fonction de la place qu'il prend sur la page avec des Media Queries, car on voit bien que sur les deux écrans, la taille du viewport n'a pas changée.

Prenons un exemple plus concret qui pourrait te servir, imagine une page de blog avec une section qui contient la liste des derniers articles publiés, et une sidebar qui contient une autre liste d'articles, les plus populaires par exemple.

Ce qu'on peut faire en HTML et CSS pour arriver à ce résultat, c'est styliser un bloc article par défaut (celui de la sidebar par exemple), et pour changer l'apparence de ceux du bloc principal, faire une surcharge CSS en ajoutant au markup HTML de l'article une class .article-horizontal.

Cela reste assez simple, mais on pourrait aller plus loin : avoir un article "à la une" tout en haut dans le bloc principal, qui aurait une image plus grande, un bouton et la date de publication.

On ne peut appliquer de Media Queries ici, car ce n'est pas la taille du viewport qui nous intéresse, mais la taille des articles qui change en fonction d'où on les place sur la page.

Tu comprends maintenant ce que viennent apporter les Container Queries ?

On va en parler un peu plus loin mais dis toi que ton code HTML va gagner en simplicité et le CSS de tes composants en maintenabilité.

Ne pas pouvoir faire de Container Queries est un problème que beaucoup d'intégrateurs ont depuis un bout de temps.

Assez longtemps pour que certains d'entre eux essayent de trouver une parade, je te conseille de regarder si tu as du temps devant toi ce talk de Heydon Pickering qui date de 2019 (donc bien avant l'arrivée des Container Queries).

Si tu n'as pas le temps je te résume la vidéo qui est composée de deux parties :

• Durant la première partie, tu as une présentation du problème que pose l'absence de Container Queries, ce que je t'ai expliqué plus haut.
• Dans la seconde partie, Heydon montre des solutions (assez tordues il faut le dire) pour produire des Containers Queries.

Sur ce CodePen de Heydon tu peux voir un exemple de Container Queries, tu n'as pas besoin de redimensionner ta fenêtre pour voir que cela fonctionne, tu peux aussi augmenter le padding sur le body et constater que le layout change, alors que le viewport n'a absolument pas bougé d'un pixel !

C'est intéressant de voir qu'en torturant le CSS il est possible d'avoir des Container Queries dès maintenant.

Mais comme on sait que cela va devenir une vraie fonctionnalité, autant s'intéresser à ce qui est prévu !

Comment ça marche ?

L'article n'est pas un tuto mais plutôt une mise en bouche, si le sujet t'intéresse et que tu as des questions, n'hésites pas à venir m'en parler sur Twitter.

Voici un exemple inspiré d'un test que j'ai réalisé :

.article {
  container-type: inline-size;
  container-name: card;
}
.article-inner {
  // On met ici le CSS par défaut de notre composant article
}

Sur la class .article je déclare un type de "container" avec la propriété container-type puis je donne un nom à mon container avec la propriété container-name (tu peux donner le nom que veux).

Sur la class .article-inner je viens donner le style par défaut de mon bloc article.

Avant de continuer, ça peut te sembler bizarre que j'utilise une class différente pour les styles par défaut, mais ne t'inquiètes pas je t'explique ce choix juste après.

@container card (min-width: 45ch) {
  .article-inner {
    // On change ici l'apparence du composant
  }
}

C'est plutôt simple non ? Si tu connais les Media Queries tu peux voir que c'est le même principe. Tu définis le style par défaut de ton composant, dans le code ci-dessus j'ai même une approche mobile-first de mon composant, puis je cible non pas les résolutions, mais les largeurs de mon composant pour surcharger le CSS par défaut ou lui donner de nouveaux styles.

Je reviens sur une petite subtilité importante : lorsque tu déclares ton container-type, tu le fais sur un élément, dans l'exemple c'est l'élément .article.

Cet élément ne peut pas ensuite être ciblé dans ta Container Query. Tu peux faire une requête dessus, comme je le fais avec un @container card, mais je ne peux pas cibler la class .article à l'intérieur de la requête. C'est pour cela que j'ai englobé le contenu de la card .article dans une div qui comporte la class .article-inner.

Si tu veux aller plus loin dans la découverte des Container Queries il y aura des liens vers des articles sur le sujet.

Si tu veux tester les Container Queries toi-même alors tu dois télécharger Google Chrome Canary. C'est une version de Google Chrome mais réservée aux développeurs.

Stylé non ? 😋

Une fois que tu as lancé Chrome Canary ce n'est pas terminé, tu dois aller dans la partie "flags" et activer les Container Queries, pour cela tu peux mettre cette adresse dans la barre d'Url : chrome://flags/#enable-container-queries.

Ensuite tu peux aller sur ce CodePen perso pour faire un test.

Si tu souhaites comprendre à quoi correspond le inline-size sur la propriété container-type, il faudra s'intéresser à la propriété contain. Mais pour faire simple : cela signifie que la requête de container doit être utilisée sur "l'axe en ligne", c'est à dire sur la largeur. Je t'avoue qu'il faut que je creuse encore le sujet car ce n'est pas encore clair pour moi. 🤔

Une petite définition rapide de la propriété contain : "La propriété contain en CSS indique au navigateur que l'élément et ses descendants sont considérés comme indépendants de l'arborescence du document autant que possible. Cela offre potentiellement des avantages en termes de performances".

Tu peux aussi aller lire cette discussion sur le Github du W3C pour comprendre la réflexion autour de ces nouvelles propriétés CSS.

Pourquoi c'est génial

C'est juste génial car cela vient bousculer la façon dont on pense le webdesign.

On a vraiment la sensation d'utiliser un composant réutilisable. L'exemple que j'ai montré est simple mais on peut imaginer faire 4 ou 5 déclinaisons d'un composant article.

Cela vient clairement bousculer la façon dont les webdesigner conçoivent les maquettes des sites Web, ils vont pouvoir vraiment penser en composants qui s'adaptent en fonction de la place qu'ils ont.

D'ailleurs si tu bosses avec un webdesigner, ça peut être cool de lui montrer, car cela va surement avoir un impact sur sa façon de penser les composants de ses créations.

Faut-il apprendre à s'en servir dès maintenant ?

Clairement oui, ça vaut vraiment le coup de passer quelques heures à lire des articles et faire des tests. Mais ce n'est que mon avis d'intégrateur Web et il ne concerne que les Containers Queries.

En effet je ne suis pas forcément du même avis pour les autres fonctionnalités à venir du CSS.

Je pense qu'il vaut mieux passer du temps sur des outils qui vont te servir à l'avenir, si l'outil que tu apprends va répondre à un problème que tu rencontres dans ton quotidien d'intégrateur, c'est une bonne idée.

Apprendre tous les sélecteurs CSS actuels et à venir est inutile, il vaut mieux apprendre ceux dont on a besoin !

Dans le cas des Container Queries, il est possible que cette nouveauté ne viennent pas résoudre un problème que tu rencontres pour le moment, après tout beaucoup de webdesigner font encore des design uniquement en desktop et ne pensent pas leurs blocs en composants réutilisables.

Je reprends l'exemple des variables CSS. Il y a plus de 4 ans, le support était à la rue, mais aujourd'hui on est à plus de 90%. Il y a de grandes chances que cela fasse pareil pour les Container Queries. Mais si t'es arrivé jusque là tu en sais suffisamment pour te la péter sur le sujet devant tes collègues. 😋

Comme promis, voici des liens si tu veux aller plus loin :

• l'article The Flexbox Holy Albatross par Heydon Pickering (je te conseille aussi de regarder son talk)
• la doc MDN sur le CSS Containement
• la doc MDN sur les Container Queries
• la doc MDN sur la propriété contain
• mon test des Container Queries sur CodePen

Si cet article t'as plu, tu peux le partager pour m'aider à donner plus de visibilité à mon travail. 🥰

À bientôt !

Seb.