Quelques requêtes sur la taille du conteneur m'auraient aidé

Les requêtes de conteneur CSS gagnent toujours du terrain et beaucoup d'entre nous se mouillent les mains, même si c'est pour de petites expériences ou autre. Ils sont excellents, mais pas tout à fait complets, prise en charge du navigateur — assez pour justifier leur utilisation dans certains projets, mais peut-être pas au point où nous pourrions être tentés de commencer à remplacer questions des médias des projets passés avec de nouvelles requêtes brillantes sur la taille des conteneurs.

Ils sont certainement pratiques cependant! En fait, j'ai déjà rencontré quelques situations où je voulais vraiment les atteindre mais je ne pouvais tout simplement pas surmonter les exigences de support. Si j'avais pu les utiliser, voici à quoi cela aurait ressemblé dans ces situations.

Toutes les démos suivantes seront mieux visualisées dans Chrome ou Safari au moment de la rédaction de cet article. Firefox prévoit de soutien des navires dans la version 109.

Cas 1 : Grille de carte

Vous deviez vous attendre à celui-ci, n'est-ce pas? C'est un schéma si commun que nous semblons tous le rencontrer à un moment donné. Mais le fait est que les requêtes de taille de conteneur auraient été un énorme gain de temps pour moi avec un meilleur résultat si j'avais pu les utiliser sur des requêtes multimédia standard.

Disons que vous avez été chargé de construire cette grille de cartes avec l'exigence que chaque carte doit conserver son rapport d'aspect 1:1 :

C'est plus dur qu'il n'y paraît ! Le problème est que le dimensionnement du contenu d'un composant sur la largeur de la fenêtre d'affichage vous laisse à la merci de la façon dont le composant répond à la fenêtre d'affichage - ainsi que de la façon dont tout autre conteneur ancêtre y répond. Si, par exemple, vous souhaitez que la taille de la police d'un en-tête de carte soit réduite lorsque la carte atteint une certaine taille en ligne, il n'existe aucun moyen fiable de le faire.

Vous pouvez définir la taille de la police dans vw unités, je suppose, mais le composant est toujours lié à la largeur de la fenêtre d'affichage du navigateur. Et cela peut causer des problèmes lorsque la grille de cartes est utilisée dans d'autres contextes qui peuvent ne pas avoir les mêmes points d'arrêt.

Dans mon projet réel, j'ai atterri sur une approche JavaScript qui :

1. Écoutez un événement de redimensionnement.
2. Calculez la largeur de chaque carte.
3. Ajoutez une taille de police en ligne à chaque carte en fonction de sa largeur.
4. Coiffez tout à l'intérieur en utilisant em unités.

Cela semble beaucoup de travail, non ? Mais c'est une solution stable pour obtenir la mise à l'échelle requise sur différentes tailles d'écran dans différents contextes.

Les requêtes de conteneur auraient été tellement meilleures car elles nous fournissent unités de requête de conteneur, comme la cqw unité. Vous l'avez probablement déjà compris, mais 1cqw est égal à 1% de la largeur d'un conteneur. Nous avons aussi le cqi unité qui est une mesure de la largeur en ligne d'un conteneur, et cqb pour la largeur de bloc d'un conteneur. Donc, si nous avons un conteneur de cartes qui est 500px large, un 50cqw valeur calcule à 250px.

Si j'avais pu utiliser des requêtes de conteneur dans ma grille de cartes, j'aurais pu configurer le .card composant en tant que conteneur :

.card { 
  container: card / size;
}

Ensuite, j'aurais pu définir une enveloppe intérieure avec padding qui évolue à 10% des .cardà l'aide de la cqw unité:

.card__inner { 
  padding: 10cqw; 
} 

C'est une bonne façon de mettre à l'échelle l'espacement entre les bords de la carte et son contenu de manière cohérente, quel que soit l'endroit où la carte est utilisée à une largeur de fenêtre donnée. Aucune requête médiatique requise !

Une autre idée? Utilisation cqw unités pour la taille de la police du contenu interne, puis appliquez un rembourrage dans em unités:

.card__inner { 
  font-size: 5cqw; 
  padding: 2em;
} 

5cqw est une valeur arbitraire - juste celle que j'ai choisie. Ce rembourrage est toujours égal à 10cqw depuis l' em l'unité est relative à la .card__inner taille de police!

Avez-vous attrapé cela? La 2em est relatif à la 5cqw taille de police définie sur le même conteneur. Les conteneurs fonctionnent différemment de ce à quoi nous sommes habitués, car em les unités sont relatives au même élément font-size value. Mais ce que j'ai rapidement remarqué, c'est que les unités de requête de conteneur se rapportent à le parent le plus proche qui est aussi un conteneur.

Par exemple, 5cqw n'évolue pas en fonction de la .card largeur de l'élément dans cet exemple :

.card { 
  container: card / size; 
  container-name: card; 
  font-size: 5cqw; 
}

Au lieu de cela, il s'adapte au parent le plus proche défini comme conteneur. C'est pourquoi j'ai mis en place un .card__inner emballage.

Cas 2 : Disposition alternée

J'avais besoin d'un autre composant de carte dans un projet différent. Cette fois, j'avais besoin que la carte passe d'une mise en page paysage à une mise en page portrait… puis de retour en paysage, et de nouveau en portrait à mesure que l'écran devient plus petit.

J'ai fait le sale boulot de faire passer ce composant en portrait à ces deux plages de fenêtres spécifiques (criez au nouvelle syntaxe de plage de requête multimédia!), mais encore une fois, le problème est qu'il est alors verrouillé sur les requêtes multimédias définies dessus, son parent et tout ce qui pourrait répondre à la largeur de la fenêtre. Nous voulons quelque chose qui fonctionne dans n'importe quelle condition sans se soucier de se demander où le contenu va casser !

Les requêtes sur les conteneurs auraient facilité la tâche, grâce à la @container régner:

.info-card {
  container-type: inline-size;
  container-name: info-card;
}

@container info-card (max-width: 500px) {
  .info-card__inner {
    flex-direction: column;
  }
}

Une requête, une fluidité infinie :

Mais attendez ! Il y a quelque chose que vous voudrez peut-être surveiller. Plus précisément, il pourrait être difficile d'utiliser une requête de conteneur comme celle-ci dans un système de conception basé sur des accessoires. Par exemple, ce .info-card peut contenir des composants enfants qui s'appuient sur des accessoires pour modifier leur apparence.

Pourquoi est-ce un gros problème ? La mise en page portrait de la carte peut nécessiter un style alternatif, mais vous ne pouvez pas modifier les accessoires JavaScript avec CSS. En tant que tel, vous risquez de dupliquer les styles requis. J'ai effectivement abordé ce sujet et comment contourner cela dans un autre article. Si vous avez besoin d'utiliser des requêtes de conteneur pour une grande partie de votre style, vous devrez peut-être baser l'ensemble de votre système de conception sur celles-ci plutôt que d'essayer de les intégrer dans un système de conception existant qui regorge de requêtes multimédias.

Cas 3 : Traits SVG

Voici un autre modèle super courant que j'ai récemment utilisé où les requêtes sur la taille du conteneur auraient abouti à un produit plus raffiné. Supposons que vous ayez une icône verrouillée avec un titre :

  
    
   
  Heading

Il est assez simple de redimensionner l'icône avec la taille du titre, même sans requêtes multimédias. Le problème, cependant, est que les SVG stroke-width pourrait devenir trop mince pour être bien remarqué à une taille plus petite, et peut-être attirer trop d'attention avec un trait super épais à une taille plus grande.

J'ai dû créer et appliquer des classes à chaque instance d'icône pour déterminer sa taille et sa largeur de trait. Ce n'est pas grave si l'icône se trouve à côté d'un titre dont le style est défini avec une taille de police fixe, je suppose, mais ce n'est pas si génial lorsque vous travaillez avec un type de fluide qui change constamment.

La taille de la police de l'en-tête peut être basée sur la largeur de la fenêtre d'affichage, de sorte que l'icône SVG doit s'ajuster en conséquence là où son trait fonctionne à n'importe quelle taille. Vous pouvez faire en sorte que la largeur du trait soit relative à celle du titre font-size en le mettant dans em unités. Mais si vous avez un ensemble spécifique de tailles de trait auquel vous devez vous en tenir, cela ne fonctionnera pas car il évolue autrement de manière linéaire - il n'y a aucun moyen de l'ajuster à un stroke-width valeur à certains points sans recourir à des requêtes multimédias sur la largeur de la fenêtre.

Mais voici ce que j'aurais fait si j'avais eu le luxe de faire des requêtes sur les conteneurs à ce moment-là :

.icon {
  container: icon / size; 
  width: 1em; 
  height: 1em; 
}

.icon svg {
  width: 100%; 
  height: 100%; 
  fill: none; 
  stroke: #ccc; 
  stroke-width: 0.8; 
}

@container icon (max-width: 70px) {
  .icon svg {
    stroke-width: 1.5; 
  }
}
@container icon (max-width: 35px) {
  .icon svg {
    stroke-width: 3;
  }
}

Comparez les implémentations et voyez comment la version de la requête du conteneur adapte le trait du SVG aux largeurs spécifiques que je veux en fonction de la largeur du conteneur.

Bonus : Autres types de requêtes sur la taille des conteneurs

OK, donc je n'ai pas rencontré cela sur un vrai projet. Mais alors que je parcourais les informations sur les requêtes de conteneur, j'ai remarqué qu'il y a des choses supplémentaires que nous pouvons interroger sur un conteneur qui sont liées à la taille ou aux dimensions physiques du conteneur.

La plupart des exemples que j'ai vus interrogent le width, max-widthet une min-width, height, block-sizeet une inline-size comme je l'ai fait tout au long de cet article.

@container info-card (max-width: 500px) {
  .info-card__inner {
    flex-direction: column;
  }
}

Mais MDN décrit deux autres choses nous pouvons interroger contre. L'un est orientation ce qui est parfaitement logique car nous l'utilisons tout le temps dans les requêtes multimédias. Ce n'est pas différent avec les requêtes de conteneur :

@media screen (orientation: landscape) { 
  .info-card__inner {
    /* Style away! */
  }
} 

@container info-card (orientation: landscape) { 
  .info-card__inner {
    /* Style away! */
  }
} 

L'autre? C'est aspect-ratio, Croyez-le ou non:

@container info-card (aspect-ratio: 3/2) { 
  .info-card__inner {
    /* Style away! */
  }
} 

Voici une démo modifiable pour jouer avec les deux exemples :

Je n'ai pas encore trouvé de bon cas d'utilisation pour l'un ou l'autre. Si vous avez des idées ou pensez que cela aurait pu vous aider dans vos projets, faites-le moi savoir dans les commentaires !