Le CSS moderne continue d'offrir des solutions innovantes et simplifiées aux défis de conception de longue date. Cependant, ces progrès introduisent souvent de nouvelles possibilités au-delà de la simple résolution de problèmes. Les requêtes de conteneurs illustrent cela, présentant des nouvelles avenues passionnantes pour la conception de la disposition. Leur similitude avec les requêtes médiatiques, cependant, peut entraîner une sous-utilisation de leurs capacités uniques.
Alors que les requêtes médiatiques ont joué un rôle déterminant dans la conception Web réactive, ils possèdent des limitations inhérentes. Ils manquent de conscience contextuelle, en s'appuyant principalement sur la taille de la fenêtre et la taille initiale de la police du navigateur (pas la taille de la police racine définie dans votre CSS).
Considérez cet exemple:
html { font-size: 32px; } body { background: lightsalmon; } @media (min-width: 35rem) { body { background: lightseagreen; } }
Intuitivement, on peut supposer que la couleur d'arrière-plan change à une largeur de la fenêtre de 1120px (35Rem 32px). Ceci est incorrect. Les requêtes multimédias ne considèrent que la taille de la police initiale du navigateur (généralement de 16px, mais réglable par l'utilisateur), comme spécifié dans la spécification de requête multimédia: les unités de longueur relative sont basées sur la valeur initiale, indépendante des valeurs déclarées.
Ce choix de conception empêche les boucles infinies dans des scénarios comme:
html { font-size: 16px; } @media (min-width: 30rem) { html { font-size: 32px; } }
Par exemple, pour créer une grille à trois colonnes à des tailles plus grandes, une requête multimédia nécessite un calcul précis de point d'arrêt. Avec les requêtes de conteneur, nous définissons la largeur de colonne minimale et la disposition s'adapte en conséquence. Si nous voulons trois colonnes 300px, nous savons qu'un conteneur 900px suffira. Cela ne fonctionnerait pas de manière fiable avec les requêtes multimédias en raison de la variabilité des tailles de conteneurs dans la fenêtre. De plus, les requêtes de conteneurs prennent en charge n'importe quelle unité, y compris
(largeur de caractère), permettant la mise en page basée sur le contenu texte. ch
.grid-parent { container-type: inline-size; } .grid { display: grid; gap: 1rem; @container (width > 90ch) { grid-template-columns: repeat(3, 1fr); } }
dans les requêtes de conteneurs (comme suggéré par Miriam Suzanne): calc()
. @container (width > calc(30ch * 3))
Considérations pratiques et solutions de contournement:
Les requêtes de conteneur nécessitent un élément de conteneur défini. Cela nécessite des éléments d'emballage, qui peuvent être lourds, en particulier avec les articles de grille ou de flexion. Cependant, l'utilisation de permet à la grille principale de servir de conteneur: repeat(auto-fit, ...)
.grid-auto-fit { display: grid; gap: 1rem; grid-template-columns: repeat(auto-fit, minmax(min(30ch, 100%)), 1fr); container-type: inline-size; }
/* 2 columns + gap */ @container (width > calc(30ch * 2 + 1rem)) { ... } /* 3 columns + gaps */ @container (width > calc(30ch * 3 + 2rem)) { ... }
Considérations flexibles:
Les requêtes de conteneur peuvent être appliquées à Flexbox, mais le rembourrage et les bordures sur les éléments Flex ne sont pas pris en compte par l'algorithme Flexbox, conduisant potentiellement à des décalages de disposition inattendus. Par conséquent, la grille est souvent préférée pour ce type de disposition réactive.
En conclusion, les requêtes en conteneurs offrent une approche plus intelligente et flexible de la conception réactive, dépassant les limites des requêtes médiatiques et déverrouillant de nouvelles possibilités créatives.
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!