Contrôler la macro et la micro-mise en page à l'ère du responsive Web design.
Le responsive design aujourd'hui
Aujourd'hui, lorsque vous utilisez le terme "responsive design", vous pensez probablement à l'utilisation de requêtes média pour modifier la mise en page lorsque vous redimensionnez une conception de la taille d'un mobile à celle d'une tablette, puis à celle d'un ordinateur.
Mais bientôt, cette perception du responsive design pourrait être considérée comme aussi obsolète que l'utilisation de tableaux pour la mise en page.
Les requêtes média basées sur la fenêtre d'affichage vous offrent des outils puissants, mais manquent de finesse. Ils ne peuvent pas répondre aux besoins des utilisateurs ni injecter des styles responsifs dans les composants eux-mêmes.
Vous pouvez utiliser les informations de la fenêtre d'affichage globale pour appliquer un style à vos composants, mais ils ne possèdent toujours pas leurs styles, et cela ne fonctionne pas lorsque nos systèmes de conception sont basés sur des composants et non sur des pages.
La bonne nouvelle, c'est que l'écosystème évolue, et ce, assez rapidement. Le CSS évolue, et une nouvelle ère de responsive design se profile à l'horizon.
Nous constatons que cela se produit environ tous les 10 ans. Il y a 10 ans, vers 2010-2012, nous avons assisté à un changement majeur avec le mobile et le responsive design, et l'émergence de CSS3.
Il s'avère donc qu'une fois de plus, l'écosystème est prêt à accueillir des changements majeurs dans CSS. Les ingénieurs de Chrome et de la plate-forme Web créent des prototypes, des spécifications et commencent à implémenter la prochaine ère du responsive design.
Ces mises à jour incluent des fonctionnalités multimédias basées sur les préférences de l'utilisateur, des requêtes de conteneur et des requêtes média pour les nouveaux types d'écrans, tels que les écrans pliables.
Réactif à l'utilisateur
Les nouvelles fonctionnalités multimédias de préférences utilisateur vous permettent de styliser des expériences Web qui s'alignent sur les préférences et les besoins spécifiques de l'utilisateur. Cela signifie que les caractéristiques média de préférence vous permettent d'adapter vos expériences utilisateur aux expériences de vos utilisateurs.
Ces caractéristiques de média de préférence utilisateur incluent :
prefers-reduced-motionprefers-contrastprefers-reduced-transparencyprefers-color-schemeinverted-colors- Et plus encore
Les fonctionnalités de préférence détectent les préférences définies par un utilisateur dans son système d'exploitation et contribuent à créer une expérience Web plus robuste et personnalisée, en particulier pour les personnes ayant des besoins d'accessibilité.
prefers-reduced-motion
Les utilisateurs qui ont défini des préférences de système d'exploitation pour réduire les animations demandent moins d'animations lorsqu'ils utilisent leur ordinateur en général. Par conséquent, il est probable qu'ils n'apprécient pas un écran d'introduction flashy, une animation de retournement de carte, un chargeur complexe ou d'autres animations flashy lorsqu'ils utilisent le Web.
Avec prefers-reduced-motion, vous pouvez concevoir vos pages en tenant compte de la réduction des mouvements et créer une expérience améliorée pour les utilisateurs qui n'ont pas défini cette préférence.
Cette carte comporte des informations des deux côtés. L'expérience de base avec réduction des animations est un fondu enchaîné pour afficher ces informations, tandis que l'expérience avec animations améliorées est un retournement de carte.
"Prefers-reduced-motion" ne signifie pas "aucun mouvement", car le mouvement est essentiel pour transmettre des informations en ligne. Proposez plutôt une expérience de base solide qui guide vos utilisateurs sans mouvements inutiles, et améliorez progressivement cette expérience pour les utilisateurs qui n'ont pas ces besoins ou préférences d'accessibilité.
prefers-color-scheme
Une autre fonctionnalité média de préférence est prefers-color-scheme. Cette fonctionnalité vous permet de personnaliser votre UI en fonction du thème préféré de l'utilisateur. Dans leur système d'exploitation, que ce soit sur ordinateur ou sur mobile, les utilisateurs peuvent définir une préférence pour les thèmes clair, sombre ou automatique, qui changent en fonction de l'heure de la journée.
Si vous configurez votre page à l'aide de propriétés CSS personnalisées, l'échange des valeurs de couleur est simple. Vous pouvez rapidement mettre à jour les valeurs de votre thème de couleurs, telles que backgroundColor et textOnPrimary, pour les adapter de manière dynamique au nouveau thème dans la requête média.
Pour tester plus facilement certaines de ces requêtes de préférence, vous pouvez utiliser les Outils de développement pour l'émulation au lieu d'ouvrir vos préférences système à chaque fois.
Concevoir pour le thème sombre
Lorsque vous concevez un thème sombre, il ne s'agit pas simplement d'inverser les couleurs de l'arrière-plan et du texte ou d'utiliser des barres de défilement sombres. Il y a quelques points que vous n'avez peut-être pas pris en compte. Par exemple, vous devrez peut-être désaturer les couleurs sur un arrière-plan sombre pour réduire les vibrations visuelles.
Au lieu d'utiliser des ombres pour créer de la profondeur et mettre en avant un élément, vous pouvez utiliser la lumière dans la couleur d'arrière-plan de l'élément pour le mettre en avant. En effet, les ombres ne sont pas aussi efficaces sur un arrière-plan sombre.
Les thèmes sombres offrent non seulement une expérience utilisateur plus personnalisée, mais ils peuvent également améliorer considérablement l'autonomie de la batterie sur les écrans AMOLED. Ce sont les écrans que l'on trouve sur les nouveaux téléphones haut de gamme, et ils sont de plus en plus populaires sur les appareils mobiles.
Une étude Android de 2018 sur les thèmes sombres a montré une économie d'énergie pouvant atteindre 60 %, en fonction de la luminosité de l'écran et de l'interface utilisateur globale. La statistique de 60 % provient de la comparaison de l'écran de lecture YouTube avec une vidéo en pause à 100 % de luminosité de l'écran, en utilisant le thème sombre pour l'interface utilisateur de l'application par rapport à un thème clair.
Dans la mesure du possible, vous devez toujours proposer une expérience de thème sombre à vos utilisateurs.
Responsive par rapport au conteneur
L'un des domaines émergents les plus intéressants du CSS est celui des requêtes de conteneur, également appelées requêtes d'élément. Il est difficile de sous-estimer l'impact de la transition d'un responsive design basé sur les pages à un responsive design basé sur les conteneurs sur l'évolution de l'écosystème de conception.
Voici un exemple des puissantes fonctionnalités offertes par les requêtes de conteneur. Vous pouvez manipuler n'importe quel style de l'élément de carte, y compris la liste de liens, la taille des polices et la mise en page globale en fonction de son conteneur parent :
Cet exemple montre deux composants identiques avec deux tailles de conteneur différentes, qui occupent tous deux de l'espace dans une mise en page créée à l'aide de CSS Grid. Chaque composant s'adapte à l'espace qui lui est alloué et se stylise en conséquence.
Ce niveau de flexibilité n'est pas possible avec les requêtes média seules.
Les requêtes de conteneur offrent une approche beaucoup plus dynamique du responsive design. Cela signifie que si vous placez ce composant de carte dans une barre latérale, une section héros ou une grille dans le corps principal d'une page, le composant lui-même possède ses informations responsives et ses tailles en fonction du conteneur, et non de la fenêtre d'affichage.
Pour cela, vous devez utiliser la règle @ @container. Elle fonctionne de la même manière qu'une requête média avec @media, mais au lieu de cela, @container interroge le conteneur parent pour obtenir des informations plutôt que la fenêtre d'affichage et l'user-agent.
.card {
container-type: inline-size;
}
@container (max-width: 850px) {
.links {
display: none;
}
.time {
font-size: 1.25rem;
}
/* ... */
}
Tout d'abord, définissez le confinement sur l'élément parent. Ensuite, écrivez une requête @container pour appliquer un style à n'importe quel élément du conteneur en fonction de sa taille, à l'aide de min-width ou de max-width.
Le code ci-dessus utilise max-width et définit les liens sur display:none, tout en réduisant la taille de la police de l'heure lorsque la largeur du conteneur est inférieure à 850px.
Fiches de requête de conteneur
Dans ce site Web de démonstration, chacune des fiches produit, y compris celle du héros, la barre latérale des articles récemment consultés et la grille de produits, sont exactement le même composant, avec le même balisage.
Aucune requête média n'est utilisée pour créer l'intégralité de cette mise en page, seulement des requêtes de conteneur. Cela permet à chaque fiche produit de passer à la mise en page appropriée pour remplir son espace. Par exemple, la grille utilise une mise en page de colonne minmax pour permettre aux éléments de s'insérer dans leur espace et de réorganiser la grille lorsque cet espace est trop compressé (ce qui signifie qu'il a atteint la taille minimale).
.product {
container-type: inline-size;
}
@container (min-width: 350px) {
.card-container {
padding: 0.5rem 0 0;
display: flex;
}
.card-container button {
/* ... */
}
}
Lorsqu'il y a au moins 350px d'espace dans la grille, la mise en page de la fiche devient horizontale en étant définie sur display: flex, qui a une direction flexible par défaut de "row".
S'il y a moins d'espace, les fiches produit s'empilent. Chaque fiche produit se stylise elle-même, ce qui serait impossible avec des styles globaux uniquement.
Mélanger les requêtes de conteneur et les requêtes média
Les requêtes de conteneur ont de nombreux cas d'utilisation, dont un composant d'agenda. Vous pouvez utiliser des requêtes de conteneur pour réorganiser les événements d'agenda et d'autres segments en fonction de la largeur disponible de leur parent.
Cette requête de conteneur de démonstration permet de modifier la mise en page et le style de la date et du jour de la semaine du calendrier, ainsi que d'ajuster les marges et la taille de la police des événements planifiés pour qu'ils s'adaptent mieux à l'espace.
Ensuite, utilisez une requête média pour modifier l'ensemble de la mise en page pour les écrans de plus petite taille. Cet exemple montre à quel point il est efficace de combiner les requêtes média (en ajustant les styles globaux ou macro) avec les requêtes de conteneur (en ajustant les enfants du conteneur et leurs microstyles).
Nous pouvons désormais envisager des mises en page macro et micro au sein d'un même composant d'interface utilisateur pour permettre des décisions de conception vraiment nuancées.
Utiliser les requêtes de conteneur dès aujourd'hui
Ces démonstrations sont désormais disponibles dans Chrome Canary, derrière un flag. Accédez à about://flags dans Canary et activez l'option #enable-container-queries.
Cela activera la prise en charge des valeurs @container, inline-size et block-size pour la propriété contain, ainsi que l'implémentation de la grille LayoutNG.
Le flag active également les fonctionnalités correspondantes des outils pour les développeurs Chrome. Découvrez comment inspecter et déboguer les requêtes de conteneur dans les outils de développement.
Styles limités
Pour exploiter les requêtes de conteneur, utilisez des styles limités avec @scope pour limiter la portée de vos sélecteurs.
Les styles limités permettent d'appliquer un style spécifique à un composant afin d'éviter les conflits de noms, ce que de nombreux frameworks et plug-ins tels que les modules CSS nous permettent déjà de faire dans les frameworks. Les styles limités vous permettent d'écrire des styles encapsulés de manière native pour les composants avec du CSS lisible, sans avoir à ajuster le balisage.
/* @scope (<root>#) [to (<boundary>#)]? { … } */
@scope (.tabs) to (.panel) {
:scope { /* targeting the scope root */ }
.light-theme :scope .tab { /* contextual styles */ }
}
La définition du champ d'application vous permet de créer des sélecteurs en forme de donut, dans lesquels vous pouvez spécifier une limite supérieure et une limite inférieure. Les sélecteurs contenus dans la règle @scope sont mis en correspondance entre ces limites.
C'est le cas, par exemple, d'un panneau d'onglets, où vous souhaitez que les onglets obtiennent les styles limités, mais que le panneau de ces onglets ne soit pas affecté par ces styles limités.
Adapté au facteur de forme
Le prochain sujet de notre conversation sur la nouvelle ère du responsive design est l'évolution des facteurs de forme et les possibilités croissantes de ce que nous devrons concevoir en tant que communauté Web (comme les écrans à forme changeante ou la réalité virtuelle).
Les écrans pliables ou flexibles, et la conception pour l'affichage sur plusieurs écrans, sont un exemple de changement de facteur de forme que nous pouvons observer aujourd'hui. L'affichage sur plusieurs écrans est une autre spécification en cours d'élaboration pour couvrir ces nouveaux facteurs de forme et besoins.
Une requête média expérimentale pour l'affichage sur plusieurs écrans pourrait nous aider ici. Il se comporte actuellement comme suit : @media
(spanning: <type of fold>). La démonstration configure une mise en page sous forme de grille avec deux colonnes : l'une a une largeur de --sidebar-width, qui est de 5rem par défaut, et l'autre est 1fr. Lorsque la mise en page est affichée sur un double écran doté d'un seul pli vertical, la valeur de --sidebar-width est mise à jour avec la valeur d'environnement du pli gauche.
:root {
--sidebar-width: 5rem;
}
@media (spanning: single-fold-vertical) {
--sidebar-width: env(fold-left);
}
main {
display: grid;
grid-template-columns: var(--sidebar-width) 1fr;
}
Cela permet d'obtenir une mise en page dans laquelle la barre latérale (la navigation dans ce cas) remplit l'espace de l'un des plis, tandis que l'interface utilisateur de l'application remplit l'autre. Cela évite un "pli" dans l'interface utilisateur.
Vous pouvez tester les écrans pliables dans l'émulateur des Outils pour les développeurs Chrome pour faciliter le débogage et le prototypage de l'affichage sur plusieurs écrans directement dans le navigateur.
Conclusion
Explorer la conception d'UI au-delà d'un écran plat est une autre raison pour laquelle les requêtes de conteneur et les styles limités sont si importants. Elles vous permettent de séparer les styles des composants de la mise en page, des styles globaux et des styles utilisateur, ce qui permet d'obtenir un responsive design plus résilient. Cela signifie que vous pouvez désormais concevoir des mises en page macro à l'aide de requêtes média basées sur la page, y compris des nuances d'affichage sur plusieurs écrans. En même temps, utilisez des micro-mises en page avec des requêtes de conteneur sur les composants, et ajoutez des requêtes média basées sur les préférences de l'utilisateur pour personnaliser l'expérience utilisateur en fonction de ses préférences et de ses besoins uniques.
Voici le nouveau responsive.
Il combine la mise en page macro et la mise en page micro, et tient compte de la personnalisation de l'utilisateur et du facteur de forme.
Chacun de ces changements constituerait à lui seul un changement considérable dans la façon dont nous concevons le Web. Mais ensemble, ils représentent un changement majeur dans la façon dont nous conceptualisons le responsive design. Il est temps de penser au responsive design au-delà de la taille de la fenêtre d'affichage et de commencer à prendre en compte tous ces nouveaux axes pour améliorer les expériences personnalisées et basées sur les composants.
La prochaine ère du responsive design est arrivée, et vous pouvez déjà commencer à l'explorer par vous-même.
web.dev/learnCSS
Pour l'instant, si vous souhaitez améliorer votre jeu CSS et peut-être revoir certaines notions de base, mon équipe lance un tout nouveau cours et une référence CSS entièrement sans frais sur web.dev. Vous pouvez y accéder via web.dev/learnCSS.
J'espère que vous avez apprécié cette présentation de la prochaine ère du responsive design et de certaines des primitives qui l'accompagneront. J'espère également que vous êtes aussi enthousiaste que moi quant à ce que cela signifie pour l'avenir de la conception Web.
Cela offre une formidable opportunité à la communauté des développeurs d'UI d'adopter des styles basés sur des composants, de nouveaux facteurs de forme et de créer des expériences adaptées aux utilisateurs.