Quelques fois des requêtes de taille de conteneur m'auraient aidé

La technologie des requêtes en conteneurs CSS devient de plus en plus mature, et de nombreux développeurs commencent à essayer de l'appliquer à divers projets, même s'il s'agit simplement d'expériences simples. Bien que le support de navigateur ne soit pas entièrement populaire, il est suffisamment pratique dans certains projets, mais peut ne pas être suffisant pour remplacer complètement les requêtes médiatiques dans des projets plus anciens.

La requête en conteneur est en effet très pratique! En fait, j'ai été dans quelques situations et j'ai été très impatiente de l'utiliser, mais je suis limité par la compatibilité du navigateur. Si la requête en conteneur peut être utilisée à ce moment-là, l'effet sera meilleur.

Toutes les démos suivantes sont mieux vues dans Chrome ou Safari au moment de la rédaction. Firefox prévoit de fournir un support dans la version 109.

cas 1: grille de cartes

Tout le monde devrait être familier avec ce cas, non? C'est un modèle très courant que nous rencontrons presque. Mais la vérité est que si les requêtes de conteneurs peuvent être utilisées à la place des requêtes multimédias standard, cela économisera beaucoup de temps et obtiendra de meilleurs résultats.

Supposons que vous ayez besoin de construire une grille de cartes qui nécessite que chaque carte maintienne un rapport d'aspect 1: 1:

c'est plus difficile qu'il n'y paraît! Le problème est que la redimensionnement des contenus des composants en fonction de la largeur de la fenêtre vous permettra de faire l'objet de la façon dont le composant réagit à la fenêtre et comment tout autre conteneur d'ancêtre réagit à la fenêtre. Par exemple, si vous souhaitez que la taille de la police du titre de la carte diminue lorsqu'elle atteint une taille en ligne spécifique, il n'y a pas de moyen fiable de le faire.

Vous pouvez définir la taille de la police à l'aide des unités VW, mais le composant est toujours lié à la largeur de la fenêtre du navigateur. Cela peut causer des problèmes lorsque la grille de carte est utilisée dans d'autres contextes qui peuvent ne pas avoir le même point d'arrêt.

Dans mon projet réel, j'ai pris la méthode JavaScript:

1. Écoutez les événements de redimensionnement.
2. Calculez la largeur de chaque carte.
3. Ajouter la taille de la police en ligne en fonction de la largeur de la carte.
4. Utilisez des unités EM pour définir le style interne.

Cela ressemble à beaucoup de travail, non? Mais il s'agit d'une solution stable pour atteindre la mise à l'échelle souhaitée dans différentes tailles d'écran et dans différents contextes.

La requête en conteneur sera meilleure car elle fournit des unités de requête de conteneur , telles que les unités CQW. Comme vous l'avez peut-être appris, 1CQW est égal à 1% de la largeur du conteneur. Nous avons également des unités CQI, qui est une mesure de la largeur en ligne du conteneur, et CQB est utilisé pour la largeur du bloc de conteneur. Donc, si nous avons un conteneur de carte de large de 500px, la valeur de 50cqw est calculée comme 250px.

Si je peux utiliser la requête de conteneur dans ma grille de cartes, je peux définir le composant .card dans le conteneur:

<code>.card { 
  container: card / size;
}</code>

Je peux ensuite configurer un wrapper interne avec un rembourrage en utilisant des unités CQW qui évolue de 10% de la largeur de .card:

<code>.card__inner { 
  padding: 10cqw; 
} </code>

C'est un bon moyen d'étendre systématiquement l'espacement entre le bord de la carte et son contenu, peu importe où la carte est utilisée à une largeur de fenêtre donnée. Aucune demande médiatique n'est requise!

Une autre idée? Utilisez les unités CQW comme taille de police du contenu interne, puis appliquez le remplissage à l'aide d'unités EM:

<code>.card { 
  container: card / size;
}</code>

5CQW est une valeur arbitraire - je viens de sélectionner une valeur. Le rembourrage est toujours égal à 10cqw, car l'unité EM est relative à la taille de la police .card__inner!

l'avez-vous remarqué? 2EM par rapport à la taille de la police 5CQW définie sur le même conteneur ! Le conteneur fonctionne différemment que nous sommes habitués car l'unité EM est relative à la valeur de taille de police du même élément. Mais j'ai rapidement remarqué que l'unité de requête de conteneur est liée au parent récent (également un conteneur) de . Par exemple, dans cet exemple, 5CQW ne fait pas évoluer sur la largeur de l'élément

:

.card

Au lieu de cela, il évoluera vers le parent le plus proche défini comme le conteneur. C'est pourquoi j'ai mis en place un wrapper

<code>.card__inner { 
  padding: 10cqw; 
} </code>

.

.card__inner Cas 2: Alternance Layout

Dans un autre projet, j'ai également besoin d'un autre composant de carte. Cette fois, j'ai besoin que la carte passe de la disposition horizontale à la disposition verticale lorsque l'écran devient plus petit ... puis revenez à la disposition horizontale et revenez à la disposition verticale.

J'ai fait ce travail décourageant pour que le composant devienne portrait dans deux gammes de fenêtres spécifiques (un salut à la nouvelle syntaxe de la plage de requête médiatique!), Mais le problème est qu'il est ensuite verrouillé sur la requête multimédia qui est définie pour cela, son parent, et tout ce qui pourrait répondre à la largeur de la fenêtre. Nous avons besoin de quelque chose qui fonctionne dans n'importe quelle situation sans nous soucier de l'endroit où le contenu sera interrompu!

La requête en conteneur peut facilement résoudre ce problème en raison de l'utilisation de la règle

:

@container

une requête, infiniment lisse:

<code>.card__inner { 
  font-size: 5cqw; 
  padding: 2em;
} </code>

Mais attendez! Il y a des problèmes dont vous pourriez être au courant. Plus précisément, l'utilisation de ces requêtes de conteneurs dans des systèmes de conception basées sur des accessoires peut être difficile. Par exemple, ce composant

peut contenir des composants enfants qui s'appuient sur Prop pour changer leur apparence.

.info-card Pourquoi est-ce important? La disposition du portrait de la carte peut nécessiter des styles alternatifs, mais vous ne pouvez pas modifier l'hélice JavaScript à l'aide de CSS. Par conséquent, vous pouvez répéter le style que vous souhaitez. J'ai en fait discuté de cela et de la façon de résoudre ce problème dans un autre article. Si vous avez besoin d'utiliser des requêtes de conteneurs pour un grand nombre de styles, vous devrez peut-être construire un système de conception entier autour d'eux, plutôt que d'essayer de les fourrer dans un système de conception existant qui s'appuie sur des requêtes multimédias.

Cas 3: SVG Stroke

Il s'agit d'un autre modèle très courant que j'ai utilisé récemment. Supposons que vous ayez une icône verrouillée avec le titre:

Même sans requêtes multimédias, il est facile de mettre à l'échelle l'icône en fonction de la taille du titre. Cependant, le problème est que le

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

de SVG peut être trop mince pour remarquer dans des tailles plus petites, et peut être trop épais et trop visible dans des tailles plus grandes.

J'ai dû créer et appliquer des classes pour chaque instance d'icône pour déterminer sa taille et sa largeur de course. C'est OK si l'icône est à côté d'un titre qui utilise une taille de police fixe, mais ce n'est pas aussi bon lors de l'utilisation d'un type de fluide en constante évolution.

La taille de la police du titre peut être basée sur la largeur de la fenêtre, de sorte que l'icône SVG doit être ajustée en conséquence et fonctionnera correctement à n'importe quelle taille. Vous pouvez définir la largeur de course par rapport à la taille de la police du titre en utilisant des unités EM. Cependant, si vous devez vous en tenir à un ensemble spécifique de tailles de course, cette méthode ne fonctionne pas car elle évolue linéairement - sans utiliser les requêtes multimédias sur la largeur de la fenêtre, vous ne pouvez pas l'ajuster à une valeur de largeur de trait spécifique sans recourir à des requêtes multimédias sur la largeur de la fenêtre.

Cependant, si j'ai la possibilité d'utiliser la requête de conteneurs, je ferai ceci:

<code>.card { 
  container: card / size;
}</code>

Comparez ces implémentations et voyez comment la version de requête de conteneur capture la course du SVG à la largeur spécifique que je veux en fonction de la largeur du conteneur.

Contenu supplémentaire: Autres types de requête de taille de conteneur

ok, je n'ai pas vraiment rencontré cela dans le projet réel. Cependant, lorsque j'ai examiné de près les informations sur les requêtes de conteneurs, j'ai remarqué que nous pouvons interroger d'autres contenus de conteneurs liés à la taille du conteneur ou à la taille physique.

Les exemples que j'ai utilisés dans ce post, principalement la largeur de requête, la largeur maximale et minimale, la hauteur, la taille du bloc et la taille en ligne.

<code>.card__inner { 
  padding: 10cqw; 
} </code>

Mais MDN décrit deux autres choses que nous pouvons interroger. L'une est la direction, ce qui a beaucoup de sens car nous l'avons utilisé dans les requêtes multimédias. Il en va de même pour les requêtes de conteneurs:

<code>.card__inner { 
  font-size: 5cqw; 
  padding: 2em;
} </code>

L'autre est le rapport d'aspect, croyez-le ou non:

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

Il s'agit d'une démonstration modifiable qui peut être utilisée pour expérimenter ces deux exemples:

Je n'ai pas encore vraiment trouvé de bons cas d'utilisation pour ces deux. Si vous avez des idées ou pensez que cela peut vous aider avec votre projet, faites-le moi savoir dans les commentaires!

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!