Dans cet extrait de Libérer la puissance du CSSnous explorons les nouvelles possibilités passionnantes offertes par les requêtes de conteneur.
Requêtes de conteneur permettre le style des éléments en fonction de l’espace disponible. Ils nous permettent de construire des composants résilients qui s’adaptent à des arrangements de mise en page infinis et inconnus. Cela contraste avec les requêtes multimédias de la fenêtre d’affichage, qui nécessitent que les changements de style soient orchestrés au niveau de la page.
Nous sommes probablement familiers avec la conception réactive et les mises en page qui répondent à la fenêtre d’affichage, comme celle illustrée ci-dessous.
Dans la conception réactive des fenêtres, il est courant de coupler une grille de mise en page à des points d’arrêt. Ces points d’arrêt concernent généralement des tailles d’appareils simplifiées, comme illustré ci-dessus, telles que les mobiles, les tablettes et les ordinateurs de bureau.
Il est important de noter que ces points d’arrêt ne prennent pas nécessairement en compte les éléments et composants individuels à l’écran, se concentrant davantage sur la manière dont les composants s’intègrent dans la grille prédéfinie. Parfois, des composants plus grands comme la navigation se transformeront séparément de la grille, mais ils utiliseront généralement les points d’arrêt globaux.
Opposons la conception réactive de la fenêtre d’affichage à la conception réactive du conteneur.
L’image ci-dessous présente des variantes d’un composant de carte. Ces trois variantes sont rendues à l’aide de requêtes de conteneur, qui sont complètement indépendantes de la fenêtre d’affichage. Les styles de carte sont ajustés en fonction de l’espace disponible.
Remarque : requêtes de conteneur sont pris en charge dans tous les navigateurs evergreen à partir de la sortie de Firefox 110. Pour étendre la prise en charge des anciens navigateurs, un polyfill est disponible.
Tout d’abord, apprenons la syntaxe pour créer des requêtes de conteneur.
Définition des requêtes de conteneur
La première étape consiste à désigner qu’un élément est un conteneur en utilisant le container-type propriété. La valeur la plus fondamentale et actuellement la mieux prise en charge est inline-size, qui dans un mode d’écriture horizontal équivaut à la largeur de l’élément. Cette définition signifie donc que nous avons l’intention de prendre en charge une requête basée sur le .container taille en ligne de l’élément :
.container {
container-type: inline-size;
}
Ajout d’un container-type à un élément le désigne officiellement comme conteneur.
Ensuite, nous allons créer la requête de conteneur réelle à l’aide de la règle at du conteneur, qui accepte un paramètre qui vous semblera familier si nous avons déjà attribué des requêtes multimédias.
Ce qui suit @container règle dit que, lorsqu’un <h2> se trouve dans un conteneur qui est 40ch large ou plus, sa couleur doit être bleue :
@container (min-width: 40ch) {
h2 {
color: blue;
}
}
Remarque : les règles que nous plaçons dans une requête de conteneur n’affectent pas le style du conteneur lui-même, mais uniquement ses enfants. Cela signifie que nous ne pouvons pas styliser un conteneur à partir de sa propre requête. Mais nous peut stylisez un conteneur avec une requête de conteneur si ce conteneur a un ancêtre qui est également défini comme conteneur.
Pour accueillir plus que des modes d’écriture horizontaux, nous pouvons mettre à jour notre requête pour utiliser la syntaxe logique de inline-sizeplutôt que de baser la requête strictement sur la « largeur » d’un conteneur :
@container (inline-size > 40ch) {
h2 {
color: blue;
}
}
Il y a plus d’options que juste inline-sizey compris block-size et aspect-ratio. Pour en savoir plus sur les requêtes de taille de conteneur disponibles et sur leur utilisation, consultez la spécification officielle.
Mise à niveau d’un composant de carte
Si nous voulions créer un composant de carte sans requêtes de conteneur, nous pourrions créer des variantes au moyen de classes de modificateurs. Et pour les variations de la taille de la carte, ces modificateurs pourraient être liés à des points d’arrêt. Cela signifie que, si la carte avait le modificateur, elle serait autorisée à changer lorsque la largeur de la fenêtre tomberait dans ce point d’arrêt.
L’image suivante montre trois variations de taille de carte et leurs classes de modificateurs respectives, où le haut .card serait considéré comme « par défaut ».
Voici un direct Démo CodePen des cartes sensibles à la fenêtre illustrées ci-dessus. (Redimensionnez la fenêtre pour voir les différents styles entrer en jeu.)
Voir le stylo
Cartes de requête multimédia de la fenêtre d’affichage par SitePoint (@SitePoint)
sur CodePen.
Changeons maintenant de perspective et réfléchissons à la manière dont nous gérerions ces variations de carte à l’aide de requêtes de conteneur.
Nous ferons toujours de la carte du dessus la carte par défaut, ce qui signifie qu’elle s’appliquera aux largeurs les plus étroites. Ce sera également la version de secours où les requêtes de conteneur ne sont pas prises en charge – un scénario important à considérer jusqu’à ce que les requêtes de conteneur aient atteint la maturité de prise en charge.
Nous allons définir la mise en page pour que la carte de taille moyenne (avec l’orientation horizontale) s’active lorsque le conteneur a une largeur de 350px ou plus grand.
Enfin, nous définirons la disposition de la carte pour utiliser son image comme arrière-plan lorsque le conteneur a une largeur de 600px ou plus grand.
Cela crée un élément de carte adaptable en fonction de la taille des conteneurs de cartes. Jouez avec ce qui suit Démo CodePen pour voir cela en action. (Notez la poignée « Resize me! » dans le coin inférieur droit.)
Voir le stylo
Requêtes de conteneur pour les cartes par SitePoint (@SitePoint)
sur CodePen.
Cet article est extrait de Libérer la puissance du CSS : techniques avancées pour des interfaces utilisateur réactivesdisponible sur SitePoint Premium.
Source link