Un aperçu des requêtes de conteneur CSS

À l'heure actuelle, les requêtes de conteneur peuvent être utilisées dans Chrome Canary par en visitant chrome: // flags et en les recherchant et en les activant. Un redémarrage sera nécessaire.

Note : Veuillez garder à l'esprit que la spécification est en cours d'élaboration et qu'elle peut changer à tout moment. Vous pouvez consulter le projet de document qui sera mis à jour au fur et à mesure de la formation de la spécification.

Quel problème les requêtes de conteneurs CSS résolvent-elles?

Il y a près de 11 ans, Ethan Marcotte nous a présenté le concept de conception sensible . Au centre de cette idée était la disponibilité des requêtes multimédias CSS qui permettaient de définir diverses règles en fonction de la taille de la fenêtre. L'iPhone avait été introduit trois ans auparavant, et nous essayions tous de comprendre comment travailler dans ce nouveau monde de lutte contre les tailles d'écran mobiles et les tailles d'écran de bureau (qui étaient beaucoup plus petites en moyenne qu'aujourd'hui).

Avant et même après l'introduction de responsive design de nombreuses entreprises se sont attaquées au problème du changement de mise en page en fonction de la taille de l'écran en proposant des sites complètement différents, souvent sous le sous-domaine de m . La conception réactive et les requêtes multimédias ont ouvert de nombreuses autres solutions de mise en page et de nombreuses années de création de bonnes pratiques pour répondre aux tailles de fenêtres. De plus, des frameworks comme Bootstrap ont gagné en popularité en grande partie grâce à la fourniture aux développeurs de systèmes de grille réactifs .

Ces dernières années, les systèmes de conception et les bibliothèques de composants ont gagné en popularité. Il y a aussi une volonté de construire une fois, de déployer n'importe où. Ce qui signifie qu'un composant développé de manière isolée est destiné à fonctionner dans n'importe quel nombre de contextes pour rendre la construction d'interfaces complexes plus efficace et cohérente.

À un moment donné, ces composants se réunissent pour créer une page Web ou une interface d'application. Actuellement, avec uniquement des requêtes multimédias, il y a souvent une couche supplémentaire impliquée pour orchestrer les mutations des composants à travers les changements de fenêtre. Comme mentionné précédemment, une solution courante consiste à utiliser des classes d'utilitaires de point d'arrêt réactives pour imposer un système de grille, comme les frameworks comme Bootstrap fournissent. Mais ces classes utilitaires sont une solution corrective pour les limitations des requêtes multimédias et entraînent souvent des difficultés pour les dispositions de grille imbriquées. Dans ces situations, vous devrez peut-être ajouter de nombreuses classes d'utilitaires de point d'arrêt sans arriver à la présentation la plus idéale.

Ou bien, les développeurs peuvent utiliser certains comportements de grille CSS et flex pour approximer la réactivité du conteneur. Mais les flex et CSS grid solutions sont limités à une définition lâche des ajustements de disposition des arrangements horizontaux aux arrangements verticaux, et ne répondent pas au besoin de modifier d'autres propriétés.

Container queries move nous allons au-delà de la seule considération de la fenêtre, et autorisons tout composant ou élément à répondre à la largeur d'un conteneur défini. Ainsi, même si vous pouvez toujours utiliser une grille réactive pour la mise en page globale, un composant de cette grille peut définir ses propres changements de comportement en interrogeant son conteneur. Ensuite, il peut ajuster ses styles selon qu'il est affiché dans un conteneur étroit ou large.

Les requêtes de conteneur nous poussent au-delà de la simple considération de la fenêtre d'affichage, et autorisent n'importe quel composant ou élément pour répondre à la largeur d'un conteneur défini.

Avec les requêtes conteneur, vous pourrez définir la gamme complète de styles d'un composant d'une manière très précise et prévisible. Vous souhaitez peut-être augmenter ou diminuer le remplissage, modifier la taille des polices, ajouter ou supprimer des images d’arrière-plan ou modifier complètement la propriété d’affichage et l’orientation des éléments enfants.

Nous examinerons bientôt d’autres exemples, mais apprenons d’abord à créer une requête de conteneur!

Premiers pas avec les requêtes de conteneur CSS

La ​​première chose à savoir sur les requêtes de conteneur CSS est que les «conteneurs» sont les éléments interrogés mais les règles dans les requêtes de conteneur n'affectent que le descendants de conteneurs. En d'autres termes, vous pouvez définir main comme un conteneur, ou peut-être article ou même lister des éléments. Ensuite, les requêtes de conteneur permettront de définir des règles sur la manière dont les éléments de ceux-ci changent à travers les tailles de conteneur.

Pour le prototype expérimental actuel, il y a une propriété requise pour définir un élément en tant que conteneur, et c'est le existant contiennent la propriété . Cela risque de changer, à la fois en ce qui concerne les valeurs utilisées, ainsi que la possibilité qu'une nouvelle propriété soit introduite à la place pour aider à définir le confinement.

Déjà, le contient prend une ou plusieurs valeurs et le support gagne pour la combinaison initiale de la taille de mise en page . La valeur de mise en page crée un contexte de formatage de bloc qui contiendra toutes ses marges afin que le contenu n'affecte pas le contenu d'un autre conteneur. La valeur size nécessite de définir des valeurs explicites de hauteur et de largeur ou de recevoir des dimensions de manière extrinsèque à partir des parents flex ou grid, car avec cette valeur, l'élément ne vérifiera plus ses dimensions à partir de ses enfants. [19659008] Le principal objectif des navigateurs qui implémentaient ces valeurs particulières en premier était de se préparer à la possibilité de requêtes de conteneurs. Ces valeurs de confinement sont configurées pour résoudre le problème de la boucle infinie qui pourrait être causée par la largeur d'un élément enfant changeant sa largeur parent qui modifie à nouveau la largeur enfant.

La proposition de requête de conteneur est rédigée par Miriam Suzanne et définit une nouvelle valeur de inline-size . Alors que size est pour le confinement dans les deux directions (largeur et hauteur), la valeur inline-size est pour le confinement basé sur la largeur.

Miriam suggère que le plus souvent les auteurs CSS essaient pour contenir des éléments basés sur la largeur. Pendant ce temps, la hauteur de est autorisée à être intrinsèque – en d’autres termes, à croître ou à diminuer en fonction du contenu de l’élément. Par conséquent, taille en ligne est considéré comme un confinement à un seul axe . Et c'est la valeur disponible dans Chrome Canary et qui nous permet de commencer à expérimenter les requêtes de conteneur.

Créons une classe à utiliser pour définir des éléments en tant que conteneurs:

 .container {
  contiennent: le style de la taille en ligne de la mise en page;
}

Nous devions inclure les valeurs de layout et inline-size pour que les requêtes de conteneur fonctionnent correctement. De plus, Miriam a conseillé d'ajouter le style pour éviter qu'une boucle infinie potentielle ne crée des propriétés telles que des compteurs susceptibles de déclencher des changements en dehors du conteneur et d'affecter sa taille, provoquant ainsi une boucle de redimensionnement.

Maintenant , avant d'écrire une requête, il y a encore quelques choses à savoir.

Lorsque vous attachez une requête de conteneur, vous ne modifiez pas le conteneur lui-même, mais plutôt les éléments de ce conteneur.

L'utilisation de inline-size crée un contexte de confinement pour les éléments dans ce conteneur. Un élément interrogé utilisera son ancêtre le plus proche avec le confinement appliqué. Ceci est important, car il est permis d'emboîter des conteneurs . Donc, si vous ne savez pas ce qu'est le conteneur ou si vous créez un conteneur imbriqué, les résultats pour les descendants peuvent changer.

Alors, à quoi ressemble réellement une requête de conteneur? La syntaxe sera familière à partir des requêtes multimédias, car elles commencent par @container et acceptent ensuite une définition telle que (min-width: 300px) .

Supposons que nous placé notre conteneur classe sur l'élément

  
 ... 
  
 ... 
  
 ... 

Nous pouvons maintenant configurer une requête de conteneur pour modifier les articles et n'importe lequel de leurs descendants qui sera basé sur la largeur de main car c'est le élément contenant. Jusqu'à présent, dans mon expérimentation, j'ai trouvé utile de penser à ceux-ci de manière similaire au concept de "mobile-first", sauf dans ce cas, il s'agit du "conteneur le plus étroit en premier". Cela signifie que je vais d'abord définir les styles de mon plus petit conteneur attendu, puis utiliser les requêtes de conteneur pour modifier les styles à mesure que le conteneur se développe.

 article {
  rembourrage: 1rem;
  taille de la police: 1rem;
}

@container (largeur min: 60ch) {
  article {
    rembourrage: 2rem;
    taille de la police: 1,25rem;
  }
}

Notez que l'utilisation d'une unité relative à la police comme ch ou em est destinée à utiliser la font-size du conteneur, mais au moment de l'écriture qui n'est pas encore terminée. Donc, pour l'instant, cela utilisera la taille de la police racine. Il y a un problème avec la spécification pour explorer d'autres fonctionnalités qui peuvent devenir interrogeables .

Les règles que nous avons ajoutées peuvent ne pas être complexes, mais elles sont pratiques. Dans les systèmes sur lesquels j'ai travaillé, les ajustements comme ce que nous avons fait avec le remplissage sont gérés en créant une série de classes utilitaires liées aux requêtes multimédias de la fenêtre. Maintenant, nous pouvons les rendre plus proportionnés aux éléments en fonction de leur taille contenue.

Si nous ajustons notre conteneur principal et définissons une grille flexible pour que les articles répondent comme des enfants flexibles, nous allons frapper ce que vous pourriez percevoir comme un écueil.

 main {
  affichage: flex;
  flex-wrap: enveloppement;
}

article {
  flex: 1 1 30 canaux;
}

Ce à quoi vous pouvez vous attendre, c'est que lorsque la largeur de l'article est inférieure au 60ch que nous avons utilisé pour notre requête de conteneur, cela prendrait un remplissage et une taille de police réduits. Cependant, comme les articles sont des enfants directs de main et main est le seul contexte de confinement les articles ne changeront pas avant la largeur de main est plus étroite que la requête de conteneur. Nous rencontrerions un problème similaire si nous utilisions la grille CSS pour mettre en page les articles.

Pour résoudre ce problème, chaque article doit avoir un élément conteneur ajouté afin de rechercher correctement la largeur de l'élément flexible. En effet, l’élément principal n’est plus représentatif de la largeur de l’élément. Dans ce cas, la résolution la plus rapide consiste à ajouter des éléments div avec notre classe container autour de chaque article.

  
 ... 
  
 ... 
  
 ... 
 

Nous devrons également remplacer notre définition flex de l'article par le nouveau div auquel nous avons également ajouté la classe de article pour faciliter la rédaction de notre règle:

 .article {
  flex: 1 1 30 canaux;
}

Le résultat est que lorsque le conteneur principal fait envelopper les éléments flexibles, le dernier article couvre toute la largeur et aura les grands styles de conteneurs. Voici un codePen de cet exemple de requêtes conteneur pour les enfants flexbox (rappel pour afficher dans Chrome Canary avec les requêtes conteneur activées comme indiqué au début!).

Nous avons également conservé main comme conteneur. Cela signifie que nous pouvons ajouter des styles pour la classe .article mais ils seront en réponse à la largeur de main pas eux-mêmes. Je prévois que cette possibilité d'avoir des règles dans les requêtes de conteneur répondant à plusieurs couches de conteneurs est la plus source de confusion pour l'implémentation initiale et l'évaluation ultérieure et le partage des feuilles de style.

Dans un proche avenir, les mises à jour des DevTools du navigateur aidera certainement à apporter des modifications DOM qui modifient ces types de relations entre les éléments et les conteneurs qu'ils peuvent interroger. Une meilleure pratique émergente sera peut-être de interroger seulement un niveau supérieur dans un bloc @container donné, et de forcer les enfants transportant leur conteneur avec eux pour réduire le potentiel d'impact négatif ici. Le compromis est la possibilité d'avoir plus d'éléments DOM comme nous l'avons vu avec notre exemple d'article, et par conséquent salir la sémantique.

Dans cet exemple, nous avons vu ce qui s'est passé avec les deux conteneurs imbriqués et aussi les effets de introduction d'une disposition flex ou grille dans un conteneur. Ce qui n'est actuellement pas réglé dans la spécification, c'est ce qui se passe lorsqu'une requête de conteneur est définie mais qu'il n'y a pas d'ancêtres de conteneur réels pour ces éléments interrogés. Il peut être décidé de considérer le confinement comme étant faux et de supprimer les règles, ou ils peuvent revenir à la fenêtre. Vous pouvez suivre le problème ouvert pour le confinement de secours et même ajouter votre opinion à cette discussion!

Règles de sélection des éléments de conteneur

J'ai mentionné précédemment qu'un conteneur ne peut pas lui-même être stylisé dans une requête de conteneur (sauf si c'est un conteneur imbriqué et répondant à la requête de son conteneur ancêtre). Cependant, un conteneur peut être utilisé dans le cadre du sélecteur CSS pour ses enfants.

Pourquoi est-ce important? Il permet de conserver l'accès aux pseudo-classes CSS et aux sélecteurs qui peuvent avoir besoin de provenir du conteneur, tels que : nth-child .

Compte tenu de notre exemple d'article, si nous le voulions pour ajouter une bordure à chaque article impair nous pouvons écrire ce qui suit:

 @container (min-width: 60ch) {
  .container: nth-child (impair)> article {
    bordure: 1px gris uni;
  }
}

Si vous avez besoin de faire cela, vous pouvez utiliser des noms de classes de conteneurs moins génériques pour être en mesure d'identifier de manière plus lisible quels conteneurs sont interrogés pour la règle.

Étude de cas: mise à niveau des teasers d'article de Smashing Magazine

Si vous visitez le profil d'un auteur ici sur Smashing ( comme le mien ) et redimensionnez votre navigateur, vous remarquerez que la disposition des éléments d'accroche de l'article change en fonction de la largeur de la fenêtre.

Activé les plus petites fenêtres, l'avatar et le nom de l'auteur sont empilés au-dessus du titre, et le temps de lecture et les statistiques des commentaires sont placés entre le titre et le contenu de l'accroche de l'article. Dans les fenêtres légèrement plus grandes, l’avatar flotte à gauche de tout le contenu, ce qui fait que le titre se rapproche également du nom de l’auteur. Enfin, dans les plus grandes fenêtres, l'article peut couvrir presque toute la largeur de la page et le temps de lecture et les statistiques des commentaires changent de position pour flotter à droite du contenu de l'article et sous le titre.

En combinant les requêtes de conteneur avec une mise à niveau vers l'utilisation des zones de modèle de grille CSS, nous pouvons mettre à jour ce composant pour être réactif aux conteneurs au lieu de la fenêtre. Nous allons commencer par la vue étroite, ce qui signifie également que les navigateurs qui ne prennent pas en charge les requêtes de conteneur utiliseront cette disposition.

Maintenant, pour cette démo, j'ai apporté le minimum de styles existants nécessaires de Smashing, et j'ai seulement apporté une modification au DOM existant qui devait déplacer le titre dans le composant header (et en faire un h2).

Voici un extrait réduit de la structure DOM de l'article pour montrer les éléments nous sommes préoccupés par la réorganisation (les noms de classe d'origine sont conservés):

Nous supposerons qu'il s'agit d'enfants directs de main et définirons main comme notre conteneur:

 main {
  contiennent: le style de format en ligne de mise en page;
}

Dans le plus petit conteneur, nous avons les trois sections empilées : en-tête, statistiques et contenu. Essentiellement, ils apparaissent dans la disposition de bloc par défaut dans l'ordre DOM. Mais nous allons continuer et attribuer un modèle de grille et chacun des éléments pertinents, car le modèle est la clé de nos ajustements dans les requêtes de conteneur.

 .article - post {
  affichage: grille;
  zones de modèle de grille:
    "entête"
    "Statistiques"
    "contenu";
  écart: 0,5rem;
}

.article - en-tête de l'article {
  zone de grille: en-tête;
}

.article - post__stats {
  zone de grille: statistiques;
}

.article - post__content {
  zone de grille: contenu;
}

Grid est idéal pour ce travail car la possibilité de définir des zones de modèle nommées facilite grandement l'application des modifications à l'arrangement. De plus, son algorithme de mise en page est plus idéal que flexbox pour la façon dont nous voulons gérer le redimensionnement des zones, ce qui peut devenir plus clair à mesure que nous ajoutons des mises à jour de requête de conteneur.

Avant de continuer, nous devons également créer un modèle de grille pour l'en-tête afin de pouvoir déplacer l'avatar, le nom de l'auteur et le titre.

Nous ajouterons à la règle pour .article - en-tête de message :

 .article - en-tête de message {
  affichage: grille;
  zones de modèle de grille:
    "pseudonyme"
    "titre du titre";
  grille-auto-colonnes: auto 1fr;
  align-items: centre;
  écart de colonne: 1rem;
  entre les rangées: 0,5rem;
}

Si vous êtes moins familier avec grid-template-areas nous nous assurons que la ligne du haut contient une colonne pour l'avatar et une pour le nom. Ensuite, sur la deuxième ligne, nous prévoyons que le titre couvre ces deux colonnes, que nous définissons en utilisant le même nom deux fois.

Surtout, nous définissons également les grid-auto-columns à écrasent le comportement par défaut où chaque colonne occupe 1fr ou une partie égale de l'espace partagé. C'est parce que nous voulons que la première colonne soit aussi large que l'avatar, et permette au nom d'occuper l'espace restant.

Maintenant, nous devons être sûrs de placer explicitement les éléments associés dans ces zones:

. article - post__image {
  zone de grille: avatar;
}

.article - post__author-name {
  zone de grille: nom;
}

.article - post__title {
  zone de grille: titre;
  taille de la police: 1,5rem;
}

Nous définissons également une font-size pour le titre, que nous augmenterons à mesure que la largeur du conteneur augmente.

Enfin, nous utiliserons flex pour organiser la liste des statistiques horizontalement, ce qui sera la disposition jusqu'à la plus grande taille de conteneur:

 .article - post__stats ul {
  affichage: flex;
  écart: 1rem;
  marge: 0;
}

Note : Safari a récemment terminé le support de gap pour flexbox, ce qui signifie qu'il est maintenant pris en charge pour tous les navigateurs modernes! 🎉

Nous pouvons maintenant passer à notre première des deux requêtes de conteneur pour créer la vue de taille moyenne. Profitons de la possibilité de créer des requêtes relatives aux polices et de les baser sur le conteneur dépassant 60ch . À mon avis, créer des éléments de contenu par rapport à la longueur de la ligne est un moyen pratique de gérer les changements dans les largeurs de conteneur. Cependant, vous pourriez certainement utiliser des pixels, des rems, des ems et peut-être plus d'options à l'avenir.

Pour cette taille moyenne, nous devons ajuster à la fois l'en-tête et les modèles de grille d'articles généraux:

 @container (min-width : 60ch) {
  .article - en-tête de l'article {
    zones de modèle de grille:
      "pseudonyme"
      "titre d'avatar";
    align-items: début;
  }

  .article - post {
    grid-template-areas: "header header" ". stats" ". content";
    grille-auto-colonnes: 5rem 1fr;
    écart de colonne: 1rem;
  }

  .article - post__title {
    taille de la police: 1,75rem;
  }
}

À cette largeur, nous voulons que l'avatar apparaisse tiré dans sa propre colonne à gauche du reste du contenu. Pour ce faire, dans l'en-tête le modèle de grille l'assigne à la première colonne des deux lignes, puis déplace le nom vers la première ligne, la deuxième colonne et le titre vers la deuxième ligne, la deuxième colonne. L'avatar doit également être aligné sur le haut maintenant, donc ajustez cela avec align-items: start .

Ensuite, nous avons mis à jour le modèle de grille d'article afin que l'en-tête occupe les deux colonnes dans la rangée du haut. Ensuite, nous utilisons le . caractère pour attribuer une zone de grille sans nom à la première colonne des deuxième et troisième rangées, en préparant le visuel de l'avatar apparaissant dans sa propre colonne. Ensuite, nous ajustons les colonnes automatiques pour rendre la première colonne équivalente à la largeur de l'avatar pour compléter l'effet.

Pour la plus grande taille de conteneur, nous devons déplacer la liste des statistiques pour qu'elle apparaisse à droite du contenu de l'article, mais sous le titre. Nous utiliserons à nouveau des unités ch pour notre "point d'arrêt", cette fois en choisissant 100ch .

 @container (min-width: 100ch) {
  .article - post {
    grid-template-area: "en-tête d'en-tête" ". content stats";
    grid-auto-columns: 5rem fit-content (70ch) auto;
  }

  .article - post__stats ul {
    flex-direction: colonne;
  }

  .article - post__title {
    largeur max: 80ch;
    taille de la police: 2rem;
  }

  .article - post__content {
    padding-right: 2em;
  }
}

Pour répondre à toutes nos exigences, nous devons maintenant nous occuper de trois colonnes, ce qui fait de la première ligne une triple répétition de en-tête . Ensuite, la deuxième ligne commence par une colonne sans nom partagée avec du contenu, puis des statistiques.

En regardant la version réelle de cette page, nous voyons que l'article ne couvre pas 100% de la largeur de la mise en page de Smashing. Pour conserver ce plafond, dans les grid-auto-columns nous utilisons la fonction fit-content qui peut être lue comme suit: "grandir jusqu'à la largeur maximale intrinsèque du contenu, mais pas plus que la valeur fournie ». Donc, nous disons que la colonne peut croître sans dépasser 70ch . Cela ne l'empêche pas de rétrécir, donc la colonne reste également sensible à son espace disponible.

Suite à la colonne content nous définissons auto pour la largeur de la colonne stats. Cela signifie qu'il sera autorisé à prendre l'espace en ligne dont il a besoin pour s'adapter à son contenu.

Maintenant, vous pensez peut-être que nous venons de faire des requêtes média, mais d'une manière légèrement différente. Ce qui – si nous nous arrêtons un moment – est plutôt génial! Cela devrait aider les requêtes de conteneur à se sentir familières et faciliter leur adaptation et leur inclusion dans votre flux de travail. Pour notre démo, c'est également le cas actuellement, car notre article unique répond actuellement à un élément parent qui lui-même ne répond qu'à la modification de la fenêtre.

Ce que nous avons vraiment fait, c'est jeter les bases de la suppression de cet article. sur une page d'article, ou sur la page d'accueil où les articles sont disposés en colonnes (pour le plaisir de cette démo, nous ignorerons les autres changements qui se produisent sur la page d'accueil). Comme nous l'avons appris dans l'exemple d'introduction, si nous voulons que les éléments répondent à la largeur des pistes de grille CSS ou des éléments flexibles, nous devons leur faire transporter leur conteneur avec eux. Ajoutons donc un élément conteneur explicite autour de chaque article au lieu de nous fier à main .

Ensuite, nous attribuerons .article - post-container comme conteneur:

 .article - post-container {
  contiennent: mise en page taille en ligne;
}

Maintenant, si nous créons une disposition de grille basée sur flex comme nous l'avons fait dans l'exemple d'introduction, nous placerons un article par lui-même au-dessus de cette grille, et deux dans la grille flexible. Cela entraîne les ajustements suivants à mesure que les conteneurs changent de taille:

La ​​vidéo permet de démontrer les changements qui peuvent maintenant se produire complètement indépendamment des requêtes multimédias basées sur les fenêtres! C'est ce qui rend les requêtes de conteneurs passionnantes et pourquoi elles sont recherchées par les développeurs CSS depuis si longtemps.

Voici le CodePen complet de cette démo, y compris la grille flex:

Opportunités et précautions pour l'utilisation des requêtes de conteneur

Vous pouvez commencer à vous préparer à utiliser les requêtes de conteneur dès aujourd'hui en les intégrant comme une amélioration progressive. En définissant des styles qui fonctionnent bien sans requêtes de conteneur, vous pouvez superposer les améliorations qui les utilisent. Ensuite, les navigateurs qui ne prennent pas en charge recevront toujours une version fonctionnelle – bien que loin d'être idéale.

Alors que nous envisageons l'avenir de pouvoir utiliser des requêtes de conteneur n'importe où, voici quelques opportunités possibles où elles seront bénéfiques, ainsi que certaines mises en garde. Tous partagent un trait: ce sont des scénarios où il est susceptible d'être considéré comme souhaitable que les changements de mise en page et de style soient indépendants de la fenêtre.

Typographie réactive

Vous connaissez peut-être le concept de typographie réactive ou fluide. Les solutions pour mettre à jour la typographie dans les largeurs de fenêtre et d'élément ont vu de nombreuses avancées, de l'assistance JavaScript, aux solutions CSS utilisant clamp () et les unités de fenêtre.

Si la spécification reçoit une unité de conteneur (que nous ' Nous en parlerons brièvement), nous pourrons peut-être réaliser une typographie intrinsèque . Mais même avec la spécification actuelle, nous pouvons définir une typographie responsive en modifiant la valeur font-size sur différentes tailles d'éléments contenus. En fait, c'est ce que nous venons de faire dans l'exemple des articles du Smashing Magazine.

Bien que cela soit passionnant du point de vue de la conception et de la mise en page, cela s'accompagne de la même prudence que les solutions de typographie fluide existantes. Pour l'accessibilité, un utilisateur doit pouvoir agrandir la mise en page et augmenter font-size à 200% de sa taille d'origine. Si vous créez une solution qui réduit considérablement la taille de la police dans des conteneurs plus petits – qui peuvent être la taille calculée lors du zoom – un utilisateur ne pourra peut-être jamais augmenter la taille de police de base de 200%. Je suis sûr que nous verrons plus de directives et de solutions à ce sujet au fur et à mesure que nous nous familiariserons tous avec les requêtes de conteneur!

Modification des valeurs d'affichage

Avec les requêtes de conteneur, nous pourrons modifier complètement les propriétés d'affichage, par exemple à partir de grille pour fléchir. Ou modifiez leurs propriétés associées, comme mettre à jour les modèles de grille. Cela permet de repositionner en douceur les éléments enfants en fonction de l'espace actuellement autorisé dans le conteneur.

C'est la catégorie dans laquelle se trouvent de nombreuses démos actuelles, car elle semble être l'une des les choses qui rendent la possibilité de requêtes de conteneurs si excitantes. Alors que les systèmes de grille réactifs sont basés sur des requêtes multimédias liées à la largeur de la fenêtre, vous pouvez vous retrouver à ajouter des couches de classes utilitaires pour obtenir le résultat que vous recherchez vraiment. Mais avec les requêtes de conteneur, vous pouvez exactement spécifier non seulement un système de grille, mais le modifier complètement à mesure que l'élément ou le composant grandit et rétrécit.

Les scénarios possibles incluent:

• modification d'un formulaire d'abonnement à une newsletter depuis mise en page horizontale à empilée;
• création de sections de modèle de grille en alternance;
• modification des proportions d'image et de leur position par rapport au contenu associé;
• cartes de contact dynamiques qui repositionnent les avatars et les coordonnées et peuvent être déposées dans une barre latérale tout aussi facilement en tant que section de largeur de page

Ici, il convient de noter que, tout comme dans notre monde de requête pré-conteneur, pour l'accessibilité, il est conseillé d'assurer un ordre logique, en particulier dans le but de tabuler les éléments interactifs comme les liens, les boutons et les éléments de formulaire

Affichage, masquage et réorganisation

Pour les composants plus complexes, les requêtes de conteneur peuvent intervenir et gérer les variations . Consider a navigation menu that includes a series of links, and when the container is reduced, some of those links should hide and a dropdown should appear.

Container queries can be used to watch sections of the navigation bar and change those individual parts independently. Contrast this to trying to handle this with media queries, where you might opt to design and develop against breakpoints with the result of a compromised, less ideal final solution.

Develop Once, Deploy Anywhere

Okay, this might be a bit aspirational. But for design systems, component libraries, and framework developers, container queries will greatly improve the ability to deliver self-defensive solutions. Components’ ability to manage themselves within any given space will reduce complications introduced when it comes time to actually add them into a layout.

At first thought, this seems like the dream, especially if you’ve been involved with design system development as I have. However, the pros and cons may be equal for some components, and you may not always want the dynamic layout or repositioning behavior. I anticipate this will be another area best practices will form to perhaps have components opt-in to using container query behavior per instance, such as through a modifier class.

For example, consider a card component that assumes that font-size should change. But, in a particular instance, the actual character counts were much longer or much shorter and those rules were suboptimal. An opt-in would likely be easier than trying to override every single container query that was attached.

What Might Change in the Spec

Currently, even the syntax is subject to change before the spec is fully finalized. In fact, it’s been released as an experiment so that as a community we can provide feedback. Miriam Suzanne has created a GitHub project to track issuesand you may react to those and add comments.

I already mentioned two key issues yet to be resolved:

• #6178: How does @container resolve when no ancestor containers have been defined?
• #5989: What container features can be queried?

Of high importance and impact is:

• Should there be a new syntax for establishing queryable containers? (#6174)
  The initial issue from Miriam proposes two options of either a new set of dedicated contain values or an entirely new property perhaps called containment. If any of these changes come through in the prototype phase, the values demonstrated at the start of this article may no longer work. So once again, note that it’s great to experiment, but be aware that things will continue changing!

Also of interest is the possibility of new container units, tracked in:

• [“container width” and “container height” units (#5888)
  This could open up a native CSS solution for intrinsic typography among other things, something like: font-size: clamp(1.5rem, 1rem + 4cw, 3rem) (where cw is a placeholder for a currently undefined unit that might represent container width).

Additional Demos And Resources

(vf, il)