Les couleurs jouent un rôle important dans le design web, mais créer une palette de couleurs peut paraître une tâche intimidante pour les développeurs et designers. De nombreux facteurs entrent en compte lorsqu'on conçoit une palette de couleurs : la marque (branding), l'information que vous souhaitez faire passer, le maintien d'une luminosité cohérente à travers les différentes couleurs, le contraste entre les ombres, la façon dont les couleurs s'affichent en mode sombre ou lumineux, etc.

CSS propose plusieurs fonctions de couleurs, mais plusieurs sont difficiles à utiliser ou créent des résultats incohérents. Dans cet article, nous allons explorer un nouveau modèle de couleur, oklch(), conçu pour offrir une façon intuitive et cohérente de créer des couleurs pour le web.

Table des matières :

• Le modèle de couleur Display P3
• Comprendre la syntaxe OKLCH
• Comment OKLCH se compare aux autres fonctions de couleurs :
  • OKLCH vs RGB et HEX
  • OKLCH vs HSL
  • OKLCH vs LCH
• Créer des palettes de couleurs avec OKLCH

Le modèle de couleurs Display P3

Lorsque le module de couleur CSS de niveau 4 est arrivé au stade recommandation en 2022, il a ajouté de nouveaux espaces de couleur. Les espaces de couleur sont, en gros, les représentations graphiques de groupes de couleurs disponibles sur un appareil qui accepte une gamme donnée de couleurs. Par exemple, l'espace de couleur sRGB est disponible sur la plupart des appareils depuis un certain temps. Les fonctions de couleur comme RGB et HSL créent des couleurs avec cet espace de couleurs.

Aujourd'hui, certains appareils acceptent l'espace de couleur Display P3, conçu par Apple, qui offre à peu près 50% de couleurs de plus que sRGB :

Le module CSS Couleur 4 propose de nouvelles fonctions de couleurs avec l'espace de couleurs Display P3 : LCH, OKLCH, LAB et OKLAB. Pour voir l'étendue de couleurs qu'offre Display P3 il vous faudra un appareil qui puisse afficher ces couleurs. Cela dit, vous pouvez toujours en profiter même si votre appareil utilise l'espace de couleur sRGB. S'il ne peut pas rendre une couleur en particulier, le navigateur choisira l'alternative la plus proche.

Comprendre la syntaxe OKLCH

La fonction de couleur oklch() prend trois paramètres obligatoires et un paramètre optionnel :

• L : la Luminosité définit la proximité de la couleur avec le blanc ou le noir, où 0% est du noir pur et 100% du blanc pur.
• C : le Chroma représente la quantité de couleur appliquée. À la valeur minimum de 0, la couleur est proche du gris, tandis que les valeurs plus élevées sont associées à une couleur plus saturée. En théorie, la valeur du chroma est infinie, mais en pratique elle est rarement supérieure à 0.5
• H : la Teinte (Hue) définit la couleur elle-même, et sa valeur va de 0 à 360. Dans le concept, H est similaire à un disque chromatique. Dans le modèle de couleur sRGB, 0 représente le rouge, mais dans le model Display P3, 0 est un rose profond.
• alpha : cette valeur optionnelle représente l'opacité, elle va de 0 à 1.

Voici un exemple de couleur écrit avec la fonction oklch() :

  .color: {
    oklch(70% 0.3 150) /* Ça donnera un vert éclatant */
  }
  .color.alpha {
    color: oklch(70% 0.3 150 / 0.5) /* Ce vert aura de la transparence */
  }

La fonction oklch() est assez intuitive. On n'a besoin que de la quantité de luminosité, de l'intensité de l'ombre et de la couleur elle-même.

Comparaison de OKLCH avec d'autres fonctions de couleurs

Le modèle de couleur oklch est plus intuitif et plus cohérent que d'autres fonctions comme rgb(), hex, hsl() et lch(). Voyons ça de plus près.

OKLCH vs RGB et HEX

Les fonctions de couleur rbg() et hex utilisent la même approche, seule change la notation. Toutes deux créent une couleur de l'espace sRGB en modifiant trois valeurs : le rouge, le vert et le bleu. rgb() et hex sont probablement les deux fonctions les plus utilisées sur le web.

Voici un exemple de couleurs rgb() et hex :

.rgb-square{
  background-color: rgb(145, 230, 200);
}
.hex-square {
  background-color: #78f25b;
}

Pouvez-vous déterminer de quelles couleurs il s'agit rien qu'en lisant le code ?

Dans cet exemple, la couleur rgb() est dominée par le vert, puis le bleu, et un peu de rouge. Comme les valeurs sont assez élevées, la couleur qui en résultera aura une assez grande luminosité. Mais comment cette information se traduit-elle en une couleur compréhensible ? La couleur hex quant ) elle est encore plus difficile à traduire car elle demande de savoir lire les valeurs hexadécimales.

Avec ces modèles, il est donc difficile de déterminer une couleur à partir de sa formule, et de savoir quelles valeurs modifier pour arriver à la couleur ou à la nuance recherchée est un vrai défi.

Voici les mystérieuses couleurs de nos exemples précédents :

Regardons maintenant une couleur écrite avec la fonction oklch() :

.oklch-square {
  background-color: oklch(45% 0.2 200);
}

Cette couleur a une luminosité de 45%, nous pouvons donc supposer qu'elle n'est pas très brillante. La valeur de chroma est 0.2, elle est donc très saturée. Et la valeur 200 de la teinte correspond à la couleur turquoise, nous pouvons donc en déduire que la couleur est une variante légèrement sombre et atténuée de turquoise.

Voici la couleur :

Avec cette fonction de couleur il est bien plus facile de déduire la couleur et de comprendre quelles valeurs modifier pour créer des variantes plus claires, plus sombres ou plus brillantes. C'est ici que les avantages de oklch() commencent à apparaître.

Comparons maintenant oklch() avec un autre modèle de couleur qui fonctionne sur le même principe, mais qui n'a pas la même cohérence.

OKLCH vs HSL

Avant le module de couleur 4, hsl() était la meilleure option pour créer intuitivement une palette de couleurs. Cette function a trois paramètres : la teinte (Hue), la saturation et la luminosité. On pourrait penser que saturation et chroma sont la même chose, mais en fait non ! La saturation renvoie à la force ou l'intensité d'une couleur, tandis que le chroma renvoie à la pureté de la couleur (combien de blanc, de noir ou de gris a été ajouté).

Comme le disent Andrey Sitnik et Travis Turner dans leur article OKLCH en CSS, pourquoi nous avons abandonné RGB et HSL, HSL est un espace de couleur distribué dans un cylindre. Ça signifie que si nous plaçons cet espace dans un graphe à deux dimensions, nous observerons que chaque couleur a la même saturation, de 0% à 100%. Mais ce n'est pas comme cela que nos yeux perçoivent la saturation. En réalité, chaque teinte a des valeurs de saturation différentes.

Remarquez la différence quand nous comparonsles espaces de couleur HSL et OKLCH et que nous supprimons la teinte :

Vous remarquerez comment OKLCH présente une teinte plus uniforme que HSL. C'est ce qui affecte la cohérence de rendu de ce dernier lorsque nous commençons à manipuler les couleurs.

Pour mieux comprendre, prenons un exemple. nous allons créer deux boutons avec les modèles hsl() et oklch() en utilisant les valeurs suivantes :

• Teinte : 90 pour le premier bouton et 270 pour le second.
• Saturation : 100% pour hsl
• Chroma : 0.5 pour oklch
• Luminosité : 50%
• Couleur du texte : blanc

Voici les boutons :

On constate d'abord que les couleurs ne sont pas les mêmes, car les cercles chromatiques de HSL et OKLCH diffèrent. On remarque que les boutons créés avec hsl() n'offrent pas le même niveau de contraste ; le bouton vert est presque illisible ! Les boutons créés avec la fonction de couleur oklch() ont un niveau de luminosité perçue assez similaires, et offrent une expérience comparable en termes de lisibilité.

Le modèle hsl() n'est pas fiable lorsqu'il s'agit de manipuler et créer des palettes de couleurs. oklch() offre la même expérience intuitive que hsl(), mais avec des rendus plus cohérents.

OKLCH vs LCH

Le modèle de couleur lch() est très similaire à oklch() et offre généralement des résultats très cohérents. Un point d'attention toutefois, comme Andrey Sitnik et Travis Turner l'ont fait remarquer dans leur article : lch() a un bug qui affecte les valeurs de chroma et luminosité du bleu (c'est à dire les teintes lch() entre 270 et 330).

oklch() a été créé comme une version de lch() qui serait plus aisée à comprendre pour les devices et offirait des résultats plus cohérents. On y est parvenu en résolvant le bug en question, en améliorant la gamme de couleurs et en ajoutant quelques autres caractéristiques.

J'espère qu'il est clair que oklch() est intuitif, accessible et, d'une manière générale, qu'il représente la meilleure option pour créer des couleurs pour le web. Mettons cela en pratique.

Créer des palettes de couleurs avec OKLCH

Ah ! la partie amusante maintenant : nous allons utiliser oklch() pour créer quatre fenêtres d'alerte. Chacune aura une palette de couleurs différente pour communiquer un message spécifique. Voici une liste de palettes de couleurs et les messages associés :

• palette "couleurs de la marque" : message produit
• palette verte : message de succès
• palette jaune : message d'avertissement
• palette rouge : message d'erreur

Pouur chaque type de message (ou d'état), nous allons créer 9 nuances de la même couleur, depuis le très clair jusqu'au sombre. Nous associerons aussi une palette de couleur neutre pour le texte de la fenêtre et nous fournirons les modes lumineux et sombre.

Allons-y !

Créer une palette de couleur neutre

L'important quand on crée des couleurs neutres c'est d'avoir un chroma très faible. Le chroma définit la pureté de la couleur, donc une valeur proche de 0 résultera en une couleur proche du gris. Comme le noir pur (ou le blanc pur) peuvent fatiguer les yeux, nous ajoutons une teinte légère en utilisant une valeur de chroma de 0.01 .

Ensuite, nous définissons notre teinte de couleur de marque. Ça pourrait être n'importe quelle valeur, mais pour cet exemple j'ai choisi 280 parce que j'aime cette nuance particulière de bleu.

Maintenant nous allons commencer à modifier les valeurs de luminosité. L'important ici c'est de commencer avec une valeur assez élevée pour la première couleur et de la réduire petit à petit à une valeur relativement basse pour la dernière couleur.

J'ai commencé avec une valeur de luminosité de 97% et je termine avec 12%. Voici les propriétés custom auxquelles je suis arrivé :

:root {
  --clr-neutral-100: oklch(97% 0.01 280);
  --clr-neutral-200: oklch(89% 0.01 280);
  --clr-neutral-300: oklch(80% 0.01 280);
  --clr-neutral-400: oklch(71% 0.01 280);
  --clr-neutral-500: oklch(60% 0.01 280);
  --clr-neutral-600: oklch(49% 0.01 280);
  --clr-neutral-700: oklch(38% 0.01 280);
  --clr-neutral-800: oklch(25% 0.01 280);
  --clr-neutral-900: oklch(12% 0.01 280);
}

Et voici la palette de couleur neutre qui en résulte :

J'ai créé cette palette simplement en regardant les valeurs et le résultat est plutôt bon ! Il y a certainement des approches plus précises pour arriver à une transition plus douce entre les nuances, mais une des caractéristiques les plus remarquables de oklch() est qu'il permet de créer des palettes de couleurs de façon intuitive et avec des résultats assez cohérents.

Avant de créer les palettes de couleurs pour les différents états, jetons un œil au design de notre fenêtre, du point de vue de l'accessibilité.

Prendre en compte les considérations d'accessibilité

Pour ce qui est des couleurs, deux points d'accessibilité importants : assurer un contraste suffisant et fournir des façons alternatives (autres que la couleur) de faire passer une information.

Améliorer le contraste

Le critère de succès 1.4.3 - contraste minimum du WCAG 2.1 indique que le contraste minimal pour un texte normal ou grand est de 4.5:1 et 3:1 respectivement. Nous devrons choisir des combinaisons de couleurs permettant ces ratios de contraste. J'ai attendu, pour discuter de ce point, d'avoir déjà créé notre palette de couleur neutre, afin que nous puissions déjà l'utiliser pour faire un prototype.

Voici notre fenêtre de message :

Améliorer la communication

Le critère de succès 1.4.1 - utilisation de la couleur du WCAG 2.1 spécifie que la couleur ne devrait pas "être utilisée comme moyen de communiquer une information, d'indiquer une action, de demander une réponse, ou de distinguer un élément visuel". En nous conformant aux techniques suggérées par le WCAG nous avons clarifié l'information du contenu textuel lui-même et nous avons ajouté une icône facilement reconnaissable pour donner une indication supplémentaire sur son contenu :

Nous avons avancé sur l'accessibilité, créons maintenant une palette de couleurs pour nos différents états.

Créer les palettes de couleurs d'états

Maintenant que nous avons une échelle de luminosité, le temps est venu de l'utiliser pour créer nos couleurs de marque. Pour ce faire, nous allons modifier les valeurs de chroma — mais comment savoir lesquelles utiliser ? Là encore, le mieux est de faire confiance à ses propres yeux, mais il y a quand même une méthode qui donne de bons résultats la plupart du temps. Mon approche consiste à modifier les valeurs de façon telle que les nuances les plus extrêmes (les valeurs 100 et 900) aient des valeurs de chroma faibles et les nuances moyennes (vers 500) des valeurs de chroma élevées. Si je devais représenter cela sur un graphique, ça donnerait ceci :

Cela va créer un groupe de nuances allant du presque blanc au presque noir avec des couleurs plus vives au milieu. Nous devrons ajouter ces valeurs de chroma à nos propriétés custom.

Vous vous rappelez que nous avons sélectionné 280 comme la valeur de base de notre teinte (Hue) et nous l'utilisons pour notre palette de couleurs neutres. Maintenant nous allons copier les valeurs, les modifier, et les ajouter à de nouvelles propriétés custom :

:root {
  --clr-brand-100: oklch(97% 0.02 280);
  --clr-brand-200: oklch(89% 0.05 280);
  --clr-brand-300: oklch(80% 0.12 280);
  --clr-brand-400: oklch(71% 0.19 280);
  --clr-brand-500: oklch(60% 0.27 280);
  --clr-brand-600: oklch(49% 0.19 280);
  --clr-brand-700: oklch(38% 0.12 280);
  --clr-brand-800: oklch(25% 0.05 280);
  --clr-brand-900: oklch(12% 0.02 280);
}

Voici notre palette de couleurs de marque :

Et maintenant il est temps de créer les palettes de couleurs pour les messages de succès, avertissement et erreur. Tout ce que nous avons à faire, c'est de copier les valeurs de luminosité et de chroma utilisées pour nos couleurs de marque et de modifier les valeurs de teinte.

Le cercle chromatique d'OKLCH est un peu différent, donc je vais juste mettre les valeurs ici :

Et voici nos nouvelles propriétés custom :

:root {
  --clr-success-100: oklch(97% 0.02 150);
  --clr-success-200: oklch(89% 0.05 150);
  --clr-success-300: oklch(80% 0.12 150);
  --clr-success-400: oklch(71% 0.19 150);
  --clr-success-500: oklch(60% 0.27 150);
  --clr-success-600: oklch(49% 0.19 150);
  --clr-success-700: oklch(38% 0.12 150);
  --clr-success-800: oklch(25% 0.05 150);
  --clr-success-900: oklch(12% 0.02 150);
  --clr-warning-100: oklch(97% 0.02 80);
  --clr-warning-200: oklch(89% 0.05 80);
  --clr-warning-300: oklch(80% 0.12 80);
  --clr-warning-400: oklch(71% 0.19 80);
  --clr-warning-500: oklch(60% 0.27 80);
  --clr-warning-600: oklch(49% 0.19 80);
  --clr-warning-700: oklch(38% 0.12 80);
  --clr-warning-800: oklch(25% 0.05 80);
  --clr-warning-900: oklch(12% 0.02 80);
  --clr-error-100: oklch(97% 0.02 20);
  --clr-error-200: oklch(89% 0.05 20);
  --clr-error-300: oklch(80% 0.12 20);
  --clr-error-400: oklch(71% 0.19 20);
  --clr-error-500: oklch(60% 0.27 20);
  --clr-error-600: oklch(49% 0.19 20);
  --clr-error-700: oklch(38% 0.12 20);
  --clr-error-800: oklch(25% 0.05 20);
  --clr-error-900: oklch(12% 0.02 20);
}

Et pour finir, voici nos palettes de couleurs pour les messages d'états :

Et voilà ! avec OKLCH, vous pouvez créer rapidement les couleurs dont vous avez besoin, juste en modifiant quelques valeurs, de façon cohérente et intuitive.

Maintenant, nous allons appliquer ces couleurs à notre composant message d'état, et nous allons les rendre compatibles avec les modes light et dark. Pour cela, nous utiliserons ces propriétés custom pour définir des variantes.

Gérer les différents états dans les fenêtres de messages

Pour ce projet, nous allons créer trois nuances : accent (pour les bordures de cartes et pour les boutons), background et texte. Nous les utiliserons partout, sauf pour l'icône et le texte du bouton primaire qui seront réalisés avec la palette de couleurs neutres.

Nous devons modifier deux nuances : 200 (background) et 700 (accents), et créer quelques propriétés custom pour chaque état.

Nous allons aussi créer quelques "valeurs atomiques de design' (design tokens).

Les design tokens sont des entités nommées qui représentent des valeurs de design atomiques. Ce sont des paires clé-valeur, dans lesquelles la clé est un nom qui représente une valeur primitive de couleur, d'espace, de taille de police, etc.

:root {
  /* Neutral color design tokens */
  --clr-text: var(--clr-neutral-800);
  --clr-text-invert: var(--clr-neutral-200);
  /* Non-neutral color design tokens */
  --clr-brand-accent: var(--clr-brand-700);
  --clr-brand-background: var(--clr-brand-200);
  --clr-success-accent: var(--clr-success-700);
  --clr-success-background: var(--clr-success-200);
  --clr-warning-accent: var(--clr-warning-700);
  --clr-warning-background: var(--clr-warning-200);
  --clr-error-accent: var(--clr-error-700);
  --clr-error-background: var(--clr-error-200);
}

Ici, nous définissons des design tokens plutôt que d'utiliser les couleurs directement, ce qui nous facilitera la vie lorsque nous créerons des variantes pour le mode sombre tout à l'heure.

Pour la simplicité, je n'ajoute ici que le style en lien avec la couleur. J'ajoute également la structure HTML utilisée pour les fenêtres :

<div class="card" data-type="brand"> <!-- This dataset will be used to define colors later -->
  <div class="card__icon-container">
    <svg width="24" height="24" viewBox="0 0 24 24" fill="none" xmlns="http://www.w3.org/2000/svg" aria-hidden="true">
      <!-- SVG path -->
    </svg>
  </div>
  <div class="card__text-container">
    <h2>Welcome to FakeApp™</h2>
    <p>This is an app that doesn't exist at all!</p>
    <p>We invite you to check what that app offers by using our tour functionality.</p>
    <div class="button__container">
      <button class="button__primary">Start tour</button>
      <button class="button__secondary">Omit</button>
    </div>
  </div>
</div>

.card {
  border: 5px solid var(--window-accent);
  background-color: var(--window-background);
}
.card__icon-container {
  background-color: var(--window-accent);
  color: var(--clr-text-invert);
}
.card__icon-container svg {
  stroke: currentColor;
}
.card h2 {
  color: var(--window-accent);
}
.button__primary {
  background-color: var(--window-accent);
  color: var(--clr-text-invert);
  border-color: transparent;
}
.button__secondary {
  background-color: transparent;
  color: var(--window-accent);
  border-color: currentColor;
}

Comme vous le voyez, j'ai créé deux variables pour chaque fenêtre : --window-accent et --window-background. J'utiliserai un attribut data- pour définir les propriétés custom de la fenêtre, grâce à nos design tokens :

.card[data-type="brand"] {
  --card-accent: var(--clr-brand-accent);
  --card-background: var(--clr-brand-background);
}
.card[data-type="success"] {
  --card-accent: var(--clr-success-accent);
  --card-background: var(--clr-success-background);
}
.card[data-type="warning"] {
  --card-accent: var(--clr-warning-accent);
  --card-background: var(--clr-warning-background);
}
.card[data-type="error"] {
  --card-accent: var(--clr-error-accent);
  --card-background: var(--clr-error-background);
}

Voici le résultat :

Nous avons vu à quel point il est facile de créer des variantes de couleurs à l'aide de design tokens, mais qu'en est-il du contraste ? Avec le modèle oklch(), si nous gardons les mêmes valeurs de luminosité sur l'ensemble des palettes, le contraste restera inchangé ou très proche. Pour le démontrer, voici une comparaison entre le contraste de la fenêtre de marque (couleurs neutres) et celle de la fenêtre d'erreur.

Modifier les valeurs de chroma en revanche pourrait avoir un impact sur le constraste, mais à moins de créer une palette de couleurs vraiment saturées, on ne devrait pas avoir de problème. À présent, la seule chose qu'il nous reste à faire est de créer des versions pour le mode sombre.

Créer des variantes pour le mode sombre

Nous pouvons ajouter les variantes "dark-mode" à nos design-tokens dans la media query CSS prefers-color-scheme pour créer les variantes respectives lorsque l'utilisateur a activé le mode sombre dans son système ou son navigateur.

@media screen and (prefers-color-scheme: dark) {
  :root {
    --clr-background: var(--clr-neutral-900);
    --clr-text: var(--clr-neutral-200);
    --clr-text-invert: var(--clr-neutral-900);
    --clr-brand-accent: var(--clr-brand-300);
    --clr-brand-background: var(--clr-brand-800);
    --clr-success-accent: var(--clr-success-300);
    --clr-success-background: var(--clr-success-800);
    --clr-warning-accent: var(--clr-warning-300);
    --clr-warning-background: var(--clr-warning-800);
    --clr-error-accent: var(--clr-error-300);
    --clr-error-background: var(--clr-error-800);
  }
}

Voici comment nos fenêtres s'afficheront en mode sombre :

Et voilà ! Vous pouvez utiliser la fonction de couleur oklch() pour créer une palette de couleurs qui produit des résultats cohérents.

Compatibilité navigateurs

Selon CanIUse, la fonction oklch() est compatible avec les principaux navigateurs. Cela dit, Firefox l'a mis en œuvre en juin 2023 et Samsung Internet n'est toujours pas compatible à la date de rédaction de cet article. On ne peut pas non plus supposer que tous les utilsateurs ont la dernière version de leur navigateur, par conséquent il est utile de créer une solution de repli si l'on souhaite utiliser ce modèle de couleur en production.

Un outil peut nous y aider : l'excellent site Huetone nous permet de créer facilement une palette de couleurs avec oklch et de l'exporter en format hexadécimal, prêt à l'usage en CSS. Nous pouvons même copier la palette sous forme de design tokens et l'utiliser dans Figma avec le plugin Design Tokens

Cet article n'est pas un tutoriel Huetone, d'autant que ce n'est pas nécessaire ! Le mode d'emploi est très clair. Voici les design-tokens que j'ai créés sur Huetone.

Prenez soin de bien nommer vos couleurs. Personnellement j'ai suivi cette convention de nommage pour mes propriétés custom : --clr-[etat]-[nuance].

N.B. : si la couleur créée par oklch n'est pas supportée par l'espace sRGB, Huetone choisira l'option la plus proche. Ce ne sera pas une réplique exacte, en particulier pour les couleurs qui ont une valeur de chroma élevée, mais ce sera suffisant pour offrir une bonne expérience, et surtout, cela conservera le ratio de contraste et l'accessibilité ne sera pas affectée.

Créer une solution de repli

Maintenant que nous avons nos couleurs alternatives, nous avons besoin de les ajouter comme solution de repli. C'est ici que la feature query @supports entre en jeu. Nous l'utilisons pour détecter si le navigateur supporte cette fonctionnalité, et sinon nous lui disons d'utiliser notre solution de repli.

La syntaxe de @supports est très simple, nous avons juste besoin d'ajouter entre parenthèses les propriétés que nous voulons détecter. Dans le cas présent, nous voulons détecter si oklch() n'est pas supporté, c'est pourquoi nous plaçons un préfixe not avant la prenthèse :

@supports not (background-color: oklch(0%, 0, 0)) {
  :root {
    --clr-neutral-100: #f3f4fc;
    --clr-neutral-200: #d9dae1;
    --clr-neutral-300: #bcbdc4;
    --clr-neutral-400: #a0a1a8;
    --clr-neutral-500: #7f8086;
    --clr-neutral-600: #5f6066;
    --clr-neutral-700: #414248;
    --clr-neutral-800: #212126;
    --clr-neutral-900: #050509;
    --clr-brand-100: #f3f4ff;
    --clr-brand-200: #d4d8fa;
    --clr-brand-300: #b0b7ff;
    --clr-brand-400: #9094ff;
    --clr-brand-500: #6d64ff;
    --clr-brand-600: #5147c9;
    --clr-brand-700: #383681;
    --clr-brand-800: #1d1e3a;
    --clr-brand-900: #05050e;
    --clr-success-100: #edf9ef;
    --clr-success-200: #c6e4cb;
    --clr-success-300: #83d494;
    --clr-success-400: #1dc15d;
    --clr-success-500: #009a46;
    --clr-success-600: #007433;
    --clr-success-700: #005121;
    --clr-success-800: #0b2813;
    --clr-success-900: #020703;
    --clr-warning-100: #fdf4e7;
    --clr-warning-200: #edd8b6;
    --clr-warning-300: #e5b562;
    --clr-warning-400: #d19500;
    --clr-warning-500: #a67600;
    --clr-warning-600: #7e5900;
    --clr-warning-700: #583d00;
    --clr-warning-800: #2e1e00;
    --clr-warning-900: #0a0500;
    --clr-error-100: #fff2f1;
    --clr-error-200: #fccecc;
    --clr-error-300: #ff9f9f;
    --clr-error-400: #ff6970;
    --clr-error-500: #ee003f;
    --clr-error-600: #b31030;
    --clr-error-700: #742028;
    --clr-error-800: #371617;
    --clr-error-900: #0c0303;
  }
}

Vous pouvez jeter un coup d'œil au projet, avec sa solution de repli, dans ce codepen :

voirMessage windows with oklch()de Cristian Diaz dansCodePen

Conclusion

CSS est en constante évolution. Le modèle de couleur oklch() nous permet d'utiliser la plus grande variété de couleurs disponible dans l'espace de couleur Display P3. Son utilisation est intuitive et, contrairement à la plupart des fonctions de couleurs précédentes, il offre des résultats cohérents.

Il y a des choses qu'on sait quand on les vit, même si l'on ne sait pas d'où nous en vient l'intuition, et même si l'on n'arrive pas à mettre des mots sur ce que l'on reconnaît exactement.

Vous ne connaissez peut-être rien aux intérieurs, mais lorsque vous vous trouvez dans un espace bien conçu, vous le percevez.

Vous pouvez aussi probablement distinguer une bonne appli d'une mauvaise, même si parfois vous ne pouvez pas expliquer exactement ce qui fait que l'une est meilleure que l'autre.

De la même manière, nos utilisateurs ne se rendent peut-être pas compte de ce qui caractérise les transitions ou les animations de nos sites web et de nos applications, mais ils sont capables de faire la différence entre ce qui est bon et ce qui ne l'est pas. Ils savent intuitivement quand le mouvement d'une application est agréable, et quand l'impression est plutôt banale ou pas fignolée — même s'ils ne peuvent pas expliquer comment ni pourquoi.

Ainsi, pour mieux comprendre ce qui dégage ces vibrations et comment éviter les mauvaises vibes lors de la création de vos propres interfaces utilisateur, j'ai rassemblé ici ce que j'ai appris ces dernières dix années sur la création de transitions et d'animations pour le web.

Même si "transition" et "animation" sont des concepts distincts en CSS, je continuerai à utiliser ces mots de manière interchangeable ici, pour signifier tout type de mouvement ou de changement.

1. Faites en sorte qu'elle soit plus courte que vous ne le pensez

Ok, ok, je comprends : vous venez de consacrer du temps et des efforts à la création d'une belle transition, vous voulez en profiter, et si vous êtes comme moi (et comme la plupart des développeurs), il se peut même que vous restiez assis à admirer votre jolie animation, en la regardant passer d'un côté à l'autre avec délectation... mais voilà :

L'indicateur n°1 d'une animation mal conçue est qu'elle dure trop longtemps.

Vos utilisateurs ne sont pas aussi enthousiastes — et donc patients — que vous. Ils sont venus ici pour faire quelque chose, et ils n'ont pas envie d'attendre plus longtemps que nécessaire, même si c'est très cool.

Mon conseil : essayez de rendre vos transitions aussi rapides que possible — sans qu'elles soient trop courtes au risque de passer inaperçues. En règle générale, il me semble que la plupart des transitions simples donnent de meilleurs résultats entre 150 et 400 millisecondes (0,15 à 0,4 seconde). Si vous avez des transitions consécutives, par exemple lorsqu'un élément sort et qu'un autre entre après, vous pouvez doubler ce chiffre et ajouter un peu de temps entre les deux (pour éviter que deux animations distinctes se bousculent).

Continuez à accélérer jusqu'à ce que vous ayez l'impression que c'est trop rapide, puis ralentissez un peu.

Cela dit, il y a toujours des exceptions, et plus le changement est important sur la page, plus la transition doit être perceptible. Il y a une grande différence entre, par exemple, une petite animation d'accentuation pour la mise à jour du nombre d'articles dans votre panier d'achat et la transition d'une page entière. Ne laissez pas les changements importants passer trop vite.

Un dernier point mérite d'être souligné : une animation ne semble pas toujours aussi longue qu'elle l'est en réalité. Une transition très lente peut donner l'impression de ne pas commencer tout de suite ; à l'inverse, une transition avec une longue traîne peut sembler terminée avant de l'être techniquement. Gardez cela à l'esprit. La perception est la réalité, la façon dont on ressent le changement est plus importante que la durée techniquement prévue dans le code.

2. Adaptez la courbe à l'action

Certes, c'est plus facile à dire qu'à faire. Vous vous dites peut-être "ok, super, mais comment puis-je savoir quel type de courbe de Bézier cubique utiliser dans une situation donnée ?"

La réponse, moyennement satisfaisante, est la suivante : essayer, se planter, recommencer (autrement dit l'expérience) sont les meilleurs maîtres en la matière.

Le mouvement est aussi subjectif que la couleur, mais il est aussi important. C'est un élément-clé du ressenti et de l'image de marque de votre site web ou de votre application.

Lorsque vous expérimentez, pensez au mouvement dans le monde réel et comparez-le au mouvement avec lequel vous travaillez dans votre application. Cette transition est-elle une confirmation positive, qui apparaît et se met en place ? Ça pourrait nécessiter une intro rapide avec une sortie douce mais rapide, comme un assistant enthousiaste qui se précipite pour signaler qu'il a terminé sa tâche.

Quid d'un message d'échec apparaissant à l'écran ? Dans ce cas, la courbe d'atténuation (easing) doit être légèrement plus lente, comme pour indiquer une légère réticence.

S'il s'agit de quelque chose d'important qui doit être connu immédiatement, la rapidité et la transparence seront une priorité. S'il s'agit de quelque chose de très critique, un mouvement plus agressif (comme une secousse) peut être nécessaire pour faire comprendre la gravité de la situation et attirer l'attention là où c'est nécessaire.

Ma recommandation est donc la suivante : investissez du temps et demandez-vous si le mouvement transmet le sentiment approprié. Ce mouvement semble-t-il cohérent avec la marque du produit ou avec la page ?

Si Pixar animait un robot faisant la même chose que votre interface utilisateur, comment se déplacerait-il ?

3. Accélérer et décélérer

Dans le monde réel, nous ne voyons pratiquement jamais un mouvement passant immédiatement à la vitesse maximale ou s'arrêtant complètement et instantanément. Nos interfaces utilisateur sembleront donc un peu plus "réelles" et intuitives si nous évitons les courbes qui créent ce type de mouvement.

Lorsque quelque chose semble anormal dans une animation, il y a de fortes chances que ce soit parce qu'elle commence ou se termine avec une soudaineté peu naturelle.

Même s'il s'agit d'un léger mouvement, je recommande d'ajouter un peu d'assouplissement (easing) à vos courbes cubic-bezier. Cette petite accélération et/ou décélération détectable peut faire la différence entre une transition fluide et une transition qui semble juste un peu mal fichue.

Jetez un coup d'œil à cette démo, où les quatre carrés tournent d'un tour complet, mais avec des easing différents :

voirSudden animations demode Josh Collinsworth dansCodePen

Remarquez que les premier et deuxième carrés ci-dessus semblent commencer ou se terminer de manière beaucoup trop abrupte.

La troisième option "lisse" donne de bien meilleurs résultats, car sa courbe personnalisée permet d'obtenir des mouvements d'accélération et de décélération plus gracieux.

Si vous souhaitez aller encore plus loin dans l'animation et donner l'impression que la physique du monde réel est appliquée, la quatrième option "inertie" fonctionne également très bien ; elle "s'enroule" et s'emballe, comme si elle était actionnée par un ressort. (N'oubliez pas qu'un peu d'inertie suffit pour ce type d'animation).

Une remarque importante sur les démarrages et les arrêts soudains : il n'y a pas de problème si l'utilisateur ne peut pas les voir. Si l'objet en question s'efface, un démarrage soudain peut être acceptable (puisque le début de l'animation ne sera pas perceptible).

Il en va de même dans le sens inverse : si un élément s'estompe jusqu'à une opacité de 0, la façon dont la courbe de transition se termine n'a pas d'importance puisqu'elle ne sera de toute façon pas visible à la fin de l'animation.

4. Moins, c'est mieux

Beaucoup de ces conseils pourraient être résumés par la formule "moins, c'est mieux".

Il est facile de se laisser emporter et d'animer tout ce qui se trouve sur la page. Mais à moins qu'il ne s'agisse de votre site web personnel et que vous ayez envie de vous lâcher un peu, trop de mouvement peut facilement faire plus de mal que de bien. Lorsqu'il s'agit d'effectuer des transitions avec CSS, la sobriété est généralement préférable à l'exagération.

Plus un élément change au cours d'une animation, plus la transition risque de paraître exagérée.

Si vous animez l'opacité de 0 à 1 (ou l'inverse), essayez plutôt une plage plus petite, comme 0,4 à 1. Si votre élément s'adapte à la taille réelle, essayez de le rendre légèrement plus petit au départ, plutôt que si petit qu'il ne peut être vu.

Un élément se met-il en place par glissement ? Dans la plupart des cas, ce type de mouvement doit être compris entre 5 et 40 pixels. S'il est inférieur, le mouvement risque d'être trop subtil pour être remarqué ; s'il est supérieur, un glissement en douceur risque de se transformer en une chute maladroite.

Voici un exemple de transition qui anime l'opacité, translateY et l'échelle. Comparez la première animation prononcée et longue (orange) avec la même transition, mais atténuée et un peu plus rapide (bleu).

voirBig vs subtle animationde Josh Collinsworth dansCodePen

En faire trop peut être pire que de ne rien faire du tout. Trouvez donc le point où la transition est juste suffisante pour être efficace, et si vous allez plus loin, faites-le avec prudence.

5. Éviter les paramètres par défaut du navigateur

Vous savez peut-être déjà que le navigateur dispose de courbes d'assouplissement intégrées : linear, ease, ease-in, ease-out et ease-in-out.

Toutefois, si ces cinq fonctions de synchronisation nommées sont pratiques et utiles dans certaines situations, elles sont également très génériques (de nombreuses animations intégrées dans des outils et des bibliothèques en ligne sont victimes de la même homogénéité, même si elles offrent un plus large éventail de choix).

Si vous voulez tirer le meilleur parti du mouvement, vous devez aller au-delà des options nommées les plus courantes.

Tout comme un site construit avec Bootstrap ou Tailwind risque de paraître générique, les courbes d'assouplissement prêtes à l'emploi peuvent souvent rendre les interfaces utilisateur fades et homogènes.

Comme alternative, VS Code a une autocomplétion étonnante pour les courbes de cubic-bezier avec un large éventail d'options ; commencez à taper cubic-bezier dans un contexte CSS, et vous devriez voir la liste déroulante suivante apparaître :

Toutes ces options sont couvertes par mon terrain de jeu sur l'easing, si vous souhaitez y jeter un coup d'œil et jouer avec les préréglages.

Une autre excellente option : ouvrez les outils de développement de votre navigateur et jouez avec les courbes d'easing qui s'y trouvent.

Tous les principaux navigateurs disposent d'un panneau d'easing qui sert de bac à sable pour essayer différentes options et procéder à des ajustements. Pour y accéder, ouvrez les outils de développement et cliquez sur l'icône de courbe située à côté d'une valeur de bézier cubique dans le panneau des styles CSS. (L'icône varie, mais le processus est fondamentalement identique dans tous les navigateurs).

Quelle que soit la manière dont vous choisirez de définir vos courbes d'easing, je vous recommande de prendre le temps de procéder à des ajustements subtils. Utilisez cubic-bezier et n'ayez pas peur de bricoler.

Vous pouvez certainement vous débrouiller avec les préréglages dans le navigateur ou dans VS Code. Et si vous utilisez le cubic-bezier sur les valeurs des mots-clés, vous avez déjà une longueur d'avance.

Cela dit, vous ne limiteriez probablement pas votre palette de couleurs à des couleurs CSS nommées prédéfinies. Vous ne voudrez peut-être pas non plus limiter vos transitions à une petite poignée de courbes prédéfinies.

6. Propriétés multiples, assouplissements multiples

Bien que ce ne soit pas toujours utile, il vous arrivera d'animer plus d'une propriété à la fois sur un même élément, comme lorsque vous mettez à l'échelle un élément avec transformation et que son opacité change également.

Vous pouvez appliquer la même courbe cubic-bezier aux deux propriétés, comme illustré ici :

/* ⛔ Ok, mais on peut faire mieux: */
.my-element {
  transition: all cubic-bezier(0.5, 0, 0.5, 1) 0.5s;
}
/* ⛔ Peut-être pas idéal non plus: */
@keyframes scale_and_appear {
  from {
    opacity: 0;
    transform: scale(0);
  }
}
.my-element {
  animation: scale_and_appear 0.5s cubic-bezier(0.5, 0, 0.5, 1) forwards;
}

Selon les cas, ça peut sembler parfait. Toutefois, dans certaines situations, la même courbe ne convient pas vraiment à toutes les propriétés faisant l'objet d'une transition.

La courbe d'assouplissement qui fonctionne bien pour la transformation peut ne pas convenir pour le fondu. C'est à ce moment-là qu'il est pratique de définir une courbe d'assouplissement unique pour chaque propriété CSS.

Dans ce cas, vous pouvez diviser les animations @keyframes par propriété ou spécifier plusieurs transitions. Vous pouvez ensuite spécifier une courbe différente pour chaque propriété, puisque la transition et l'animation peuvent accepter plusieurs valeurs :

/* ? C'est mieux; chaque propriété a sa propre courbe */
.my-element {
  transition: opacity linear 0.5s, transform cubic-bezier(
        0.5,
        0,
        0.5,
        1
      ) 0.5s;
}
/* ? Utilisez deux animations */
@keyframes scale {
  from {
    transform: scale(0);
  }
}
@keyframes appear {
  from {
    opacity: 0;
  }
}
.my-element {
  animation: scale 0.5s cubic-bezier(0.5, 0, 0.5, 1) forwards, appear
      0.5s linear forwards;
}

Voici une démo ; lorsque les cases entrent et sortent en alternance, remarquez que l'opacité et l'échelle suivent la même accélération pour le carré de gauche. À droite, en revanche, l'opacité suit sa propre courbe linéaire.

voirVarying easings per propertyde Josh Collinsworth dansCodePen

Lequel est le meilleur ? Tout dépend de l'effet recherché.

Encore une fois, cet effet ne se produit pas très souvent, mais il est très pratique lorsqu'il se produit, et facile à oublier, ce qui lui vaut une place sur la liste.

Vous pouvez même aller jusqu'à modifier la durée de chaque propriété, mais faites attention à ce que les choses ne se désynchronisent pas si vous décidez d'aller aussi loin.

7. Utiliser des délais échelonnés

Lors de la transition de plusieurs éléments (ou d'un élément composé de plusieurs parties), ne sous-estimez pas l'effet que peuvent avoir les délais d'animation ou de transition, en particulier lorsqu'ils sont décalés.

Jetez un coup d'œil à cet exemple CodePen ; chaque ligne utilise un nouveau type de délai d'animation pour créer un effet différent :

voirPlay more with delayde Josh Collinsworth dansCodePen

Dans le codepen ci-dessus, la première ligne transitionne d'un seul coup. C'est bien, mais ce n'est pas particulièrement net.

Dans chaque ligne suivante, différents degrés de retard sont appliqués à chaque lettre, pour créer un effet ludique de "rebond". Il y en a même un qui va à l'envers et un autre qui fait apparaître la ligne du milieu vers l'extérieur.

Cependant, n'oubliez pas que le moins est le mieux. Il est très facile d'exagérer les animations de ce type, surtout lorsqu'il y a beaucoup d'éléments en transition. J'ai rendu cet exemple beaucoup plus exagéré que ce que je recommanderais généralement, juste à des fins de démonstration. Il est probablement un peu trop chargé pour la plupart des travaux d'interface utilisateur.

Cela dit, il est possible d'appliquer cet effet à une échelle plus subtile. Des points dans un écran de chargement, peut-être ? Lorsqu'un tiroir ou un menu hamburger est ouvert, chaque élément peut apparaître avec un léger retard.

Là encore, l'effet doit être court et subtil. Mais lorsqu'ils sont bien appliqués, les délais échelonnés peuvent contribuer à porter les transitions web au top.

8. Les entrées sortent, les sorties entrent

Si vous avez examiné divers types de courbes d'easing, vous avez peut-être remarqué qu'elles se présentent généralement sous trois formes : un ease-in (qui commence plus lentement), un ease-out (qui se termine plus lentement) et in-out (qui est essentiellement les deux : plus rapide au milieu et plus lent au début et à la fin).

Le problème avec les transitions, c'est qu'on veut souvent que la transition in soit une transition ease-out et que la transition out soit une transition ease-in.

...Ok, c'était probablement aussi déroutant pour vous de le lire que pour moi de l'écrire... Revenons en arrière.

Supposons que vous ayez une animation dans laquelle un élément quitte la page tandis qu'un autre apparaît pour prendre sa place, comme une transition de page ou un glissement entre deux images dans une boîte.

L'utilisateur perçoit cela comme une transition d'interface utilisateur. Mais en coulisses, il s'agit en fait de deux transitions : le départ de l'ancien élément, suivi de l'entrée du nouvel élément.

Cela signifie que si vous faites sortir un élément (out) et que vous voulez qu'il démarre lentement, vous avez besoin d'un ease-in.

Inversement, lorsqu'un élément entre (in), il doit normalement s'arrêter progressivement. Dans ce cas, il faut un ease-out.

Ces deux éléments s'associent pour créer l'effet d'un mouvement homogène.

9. S'appuyer sur l'accélération matérielle

Toutes les propriétés CSS ne peuvent pas être animées ou faire l'objet d'une transition fluide sur tous les appareils et navigateurs. En fait, seules quelques-unes sont capables d'exploiter l'accélération matérielle d'un appareil pour obtenir les transitions les plus fluides et les plus rapides possibles.

Il n'est pas nécessaire de comprendre ce qu'est l'accélération matérielle pour en tirer parti. Mais si vous êtes curieux, sachez que cela signifie que le navigateur peut faire appel à l'unité de traitement graphique (GPU) de l'appareil pour accélérer considérablement le rendu et le rendre plus fluide, mais uniquement sous certaines conditions.

Propriétés qui peuvent toujours être accélérées par le matériel :

• transform (y compris toutes les formes de translate, scale et rotate, ainsi que tous leurs équivalents 3d)
• opacity

Propriétés qui peuvent parfois être accélérées par le matériel :

• Certaines propriétés SVG
• filter, en fonction du navigateur et du filtre

D'autres éléments non-CSS, comme le canvas et le WebGL, peuvent également bénéficier de l'accélération matérielle. Je n'en parlerai pas ici.

Le tl;dr de tout ce qui précède est : Si vous souhaitez déplacer, mettre à l'échelle ou faire pivoter un élément, utilisez toujours la propriété CSS transform.

L'application d'une transformation n'affecte pas la mise en page, ce qui minimise les recalculs et permet au navigateur de fonctionner en douceur. La plupart des animations et des transitions les plus courantes que vous pouvez utiliser sur le web peuvent être réalisées en combinant transform et opacity.

Mais quoi que vous fassiez, évitez de modifier directement la taille ou l'emplacement d'un élément. Si vous modifiez une propriété susceptible d'affecter la disposition des éléments sur la page - hauteur, largeur, bordure, marge, padding, etc. - vous risquez de ralentir sensiblement la page en raison des calculs nécessaires pour effectuer cette modification.

Si vous devez animer de telles propriétés, veillez à les tester sur tous les appareils et navigateurs possibles. D'après mon expérience, Safari en particulier ne traite pas les animations de manière performante par défaut, surtout sur iOS. Firefox n'est pas loin derrière, mais vous ne vous en rendrez peut-être pas compte si vous ne testez que sur des appareils puissants. Une grande partie du monde vit sur des Androïdes bon marché ; n'oubliez pas de les inclure dans vos tests.

Ce n'est pas parce que quelque chose peut être accéléré au niveau matériel qu'il le sera. C'est le navigateur qui prend la décision finale.Une raison potentielle pour laquelle il peut se retirer : le GPU est plus rapide, mais il consomme aussi plus d'énergie. Par conséquent, si l'appareil est peu gourmand en énergie ou en mode d'économie de la batterie, le navigateur peut préférer la batterie aux performances graphiques.

10. Utilisez will-change si nécessaire

Si vous rencontrez des problèmes avec des animations qui devraient être fluides et performantes en théorie, mais qui semblent hachées ou guindées en pratique (encore une fois : c'est généralement dans Safari pour moi, mais votre kilométrage peut varier), utilisez la propriété will-change.

Je n'entrerai pas trop dans les détails techniques, mais la propriété will-change vous permet essentiellement d'indiquer au navigateur ce qui va changer (assez facile à retenir), afin qu'il puisse ignorer d'autres calculs. C'est un peu comme si vous indiquiez à l'avance au restaurant que tout votre groupe ne commandera qu'un menu limité ; cela permet de gagner du temps en indiquant à la cuisine/au navigateur ce sur quoi il doit se concentrer et ce dont il n'a pas besoin de se préoccuper.

Exemple : si vous êtes certain que la seule chose qui va changer avec un élément est sa propriété transform, et que vous pouvez en toute confiance le faire savoir au navigateur à l'avance via will-change : transform, il peut en toute sécurité ignorer toutes les autres étapes qu'il aurait dû suivre pour rendre à nouveau cet élément lorsque quelque chose change sur la page.

Dans le meilleur des cas, lorsqu'il est utilisé avec des propriétés qui n'affectent pas la mise en page, il permet au navigateur de décharger entièrement le calcul sur le GPU afin d'obtenir un taux de rafraîchissement plus élevé et des performances plus fluides.

Cependant, will-change n'est pas une solution miracle. En fait, s'il est utilisé à outrance, il peut nuire aux performances.

En effet, le navigateur crée une nouvelle couche (un peu comme un nouveau niveau d'indice z) pour chaque élément auquel est appliqué un will-change, ce qui rend les choses un peu plus complexes à composer. Utilisé judicieusement, cet échange vaut son prix. Utilisé sans précaution, cependant, il pourrait créer encore plus de travail pour le navigateur. Comme le dit MDN :

Certaines sources vont même jusqu'à recommander d'appliquer will-change avant une animation ou une transition, puis de le retirer après.

Là encore, le meilleur conseil est de faire des tests approfondis.

Bonus : respecter les préférences de l'utilisateur

Les utilisateurs peuvent indiquer, via les paramètres de leur appareil, s'ils préfèrent les mouvements réduits.

Les raisons pour lesquelles un utilisateur peut le faire sont nombreuses et variées. Il y a tout d'abord des raisons médicales : un utilisateur peut avoir des vertiges, des nausées ou même des crises d'épilepsie lorsqu'il est exposé à des mouvements excessifs. Ou encore, un utilisateur peut simplement trouver que trop de mouvements le distraient ou l'ennuient.

La raison n'a pas vraiment d'importance ; c'est à nous, développeurs, qu'il incombe de tenir compte des préférences de l'utilisateur, quelles qu'elles soient.

Nous pouvons le faire en CSS, à l'aide d'une requête média (comme celle-ci, tirée de MDN) :

@media (prefers-reduced-motion) {
  /* styles to apply if the user's settings
     are set to reduced motion */
}

Nous pouvons également utiliser JavaScript. Dans cet exemple, nous allons vérifier s'il existe une préférence pour les mouvements réduits et ajouter une classe à la balise si c'est le cas :

const prefersReducedMotion = window.matchMedia(
  '(prefers-reduced-motion: reduce)'
).matches
if (prefersReducedMotion) {
  document.documentElement.classList.add('reduce-motion')
}

En suivant cet exemple JavaScript, nous pourrions ensuite ajouter des feuilles de style CSS à des éléments ciblés de la page pour définir des dérogations :

.reduce-motion {
  /* Select stuff here and reduce motion */
}

Notez simplement que si vous utilisez JavaScript, vous voudrez que la page soit progressivement améliorée, afin de vous assurer qu'il n'y a pas d'éclair de mouvement avant l'exécution du script, et que les utilisateurs qui ont désactivé JavaScript ne sont pas exclus de la page. L'idéal est donc de combiner les deux techniques.

Pour ce qui est de ce que nous devons faire exactement avec notre CSS dans ces cas, n'oubliez pas que la réduction du mouvement ne signifie pas qu'il n'y a pas de mouvement, ni même qu'il n'y a pas d'animation du tout.

Une technique que j'utilise souvent consiste à modifier les animations des images clés pour n'utiliser l'opacité que lorsqu'une préférence de mouvement réduit est détectée :

@keyframes slide_in {
  from {
    opacity: 0;
    transform: translateY(2rem);
  }
}
@keyframes slide_in_reduced {
  from {
    opacity: 0;
  }
}
.animated-thing {
  animation-name: slide_in;
}
@media (prefers-reduced-motion) {
  .animated-thing {
    animation-name: slide_in_reduced;
  }
}

Ce n'est pas parce qu'un utilisateur préfère un mouvement minimal qu'il n'apprécie pas les transitions.

De plus, dans certaines situations, il est préférable de ne pas modifier les mouvements. Par exemple, si vous affichez une barre de progression pendant le chargement d'un élément en arrière-plan, ou un indicateur de lecture sur un fichier audio ou vidéo, il s'agit d'un élément d'information clé de l'interface utilisateur. Plutôt que d'éliminer complètement cet indicateur, envisagez de trouver un moyen de rendre le mouvement subtil et discret. Il est possible de permettre à l'utilisateur de masquer le mouvement. Il est également possible de représenter l'information différemment (un compteur de pourcentage numérique au lieu d'une barre animée, par exemple).

Au minimum, les utilisateurs devraient pouvoir interrompre toutes les animations continues, y compris les vidéos et les gifs. Toutefois, dans l'idéal, nous devrions anticiper leurs besoins en fonction des préférences de leur appareil, au lieu de les forcer à gérer quelque chose qu'ils ont déjà indiqué qu'ils préféraient ne pas voir.

Je vous renvoie à cet article de Val Head pour Smashing Magazine, qui approfondit la question du design avec des mouvements réduits. Il s'agit d'un vaste sujet en soi, mais j'espère que ce conseil vous fournira des indications générales.

Mettre tout cela en place

Cette démo CodePen permet d'illustrer comment la combinaison des astuces de cet article peut complètement changer la sensation d'une transition d'interface utilisateur. Cliquez sur le bouton "Exécuter l'animation" d'un côté ou de l'autre pour voir la transition des éléments de cette colonne.

voirAnimation tips visualizedde Josh Collinsworth dansCodePen

Remarquez que les deux côtés ont essentiellement la même animation ; les boîtes changent d'échelle, se déplacent et s'estompent dans les deux cas. Mais les détails de cette transition transforment complètement l'effet (sans jeu de mots).

Dans la colonne de gauche (rouge-orange), les éléments ne sont pas décalés dans le temps ; ils apparaissent tous en même temps, avec une grande variation d'opacité, de position et d'échelle. La transition dure également assez longtemps et utilise la courbe ease-out par défaut du navigateur, ce qui n'est pas mauvais dans ce cas, mais pas optimal non plus.

Dans la colonne de droite (bleue), en revanche, l'animation est décalée, de sorte que les éléments entrent l'un après l'autre. Le délai et la durée totale de la transition sont tous deux assez minimes, et les effets sont toujours présents, mais beaucoup plus subtils. Enfin, l'assouplissement est une courbe de bezier personnalisée.

J'espère que cette démo vous permettra de vous rendre compte de l'énorme différence que peuvent faire de petites modifications.

Récapitulatif

Bonne chance pour créer vos propres animations sur le web ! J'espère que cet article a été engageant et utile, et que vous vous sentez mieux équipé pour créer des expériences interactives encore plus fortes.

Comme toujours, n'hésitez pas à nous faire part de vos commentaires ou de vos questions (dans l'article original), et merci de votre lecture !

Les variables CSS (également appelées propriétés personnalisées CSS, custom properties en anglais) peuvent contenir toutes sortes de choses. Certaines n'étaient pas évidentes pour moi, c'est pourquoi j'ai décidé d'écrire cet article.

Pour être clair, cet article se concentre sur ce que vous pouvez mettre dans une variable CSS — avec une démonstration d'animation vers la fin parce que je ne pouvais pas m'en empêcher. Si vous recherchez des conseils plus généraux sur l'utilisation des variables CSS, il existe d'autres excellents articles pour cela.

Valeurs unitaires et un peu de maths

Commençons par le plus simple. Il est courant de mettre des valeurs numériques avec des unités dans une variable CSS. Celles-ci sont formellement connues sous le nom de dimensions.

:root {
  --nice-padding: 20px;
  --decent-font-size: 1.25rem;
}
article {
  padding: var(--nice-padding);
  font-size: var(--decent-font-size);
}

Les variables peuvent contenir les résultats de calculs impliquant d'autres variables via calc().

:root {
  --image-width: 800px;
  /* calculate height to preserve a 4:3 aspect ratio */
  --image-height: calc(var(--image-width) / (4 / 3));
}
img {
  width: var(--image-width);
  height: var(--image-height);
}

De même, les variables peuvent être utilisées avec les fonctions CSS intégrées.

:root {
  --min: 1rem;
  --max: 4rem;
  --clamped-font-size: clamp(var(--min), 2.5vw, var(--max));
}
p {
  font-size: var(--clamped-font-size);
}

Valeurs numériques sans unité

Les variables peuvent également contenir des valeurs numériques sans unité. Certaines propriétés CSS utilisent directement ces valeurs.

:root {
  --obnoxiously-big-number: 9001;
}
.important-modal {
  z-index: var(--obnoxiously-big-number);
}

Mais d'autres fois, vous pouvez vouloir appliquer des unités à ces valeurs. Ça peut se faire très simplement avec une multiplication dans une expression calc().

:root {
  --magic-number: 41;
}
.crazy-box {
  width: calc(var(--magic-number) * 1%);
  padding: calc(var(--magic-number) * 1px);
  transform: rotate(calc(var(--magic-number) * 1deg));
}

Des trucs non numériques

Les variables CSS ne sont pas uniquement destinées aux chiffres. Elles peuvent contenir des mots-clés prédéfinis que les propriétés reconnaissent.

:root {
  --bullets: circle;
  --casing: uppercase;
}
ul {
  list-style-type: var(--bullets);
  text-transform: var(--casing);
}

Il existe également des identifiants personnalisés qui pointent vers des éléments que vous avez définis et nommés, comme un nom d'animation ou une zone de grille, comme indiqué ci-dessous.

:root {
  --layout-position: center-stage;
}
body {
  grid-template-areas: 'left center-stage right';
}
main {
  grid-area: var(--layout-position);
}

Chaînes de contenu

Les pseudo-éléments ::before et ::after utilisent la propriété content pour afficher, eh bien... du contenu. Ce contenu peut être un certain nombre de choses différentes, mais il s'agira souvent de chaînes de caractères (string).

Le CSS suivant montre que le contenu est alimenté par des variables de type string. Vous pouvez également voir comment concaténer des variables de type string avec d'autres chaînes de caractères et comment extraire une valeur de type string d'un attribut avec attr().

:root {
  --open: '(';
  --close: ')';
  --heading-hint: ' ' var(--open) 'this is a heading' var(--close);
  --link-hint: ' ' var(--open) attr(href) var(--close);
}
h1::after {
  content: var(--heading-hint);
}
a::after {
  content: var(--link-hint);
}

Voici une démo pour vous montrer le résultat.

voirCSS Variables with Content Stringsde lonekorean dansCodePen

Images

Les variables CSS peuvent également contenir des images. Les images peuvent également être affichées dans le contenu, mais on les voit sans doute plus couramment dans background-image.

:root {
  /* image from an external URL (PNG in this case) */
  --image-from-somewhere: url(https://codersblock.com/assets/images/logo.png);
  /* image from embedded data (SVG in this case) */
  --image-embedded: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 512 512'%3E%3Cpath d='M8 256c0 136.966 111.033 248 248 248s248-111.034 248-248S392.966 8 256 8 8 119.033 8 256zm248 184V72c101.705 0 184 82.311 184 184 0 101.705-82.311 184-184 184z'%3E%3C/path%3E%3C/svg%3E");
}
.a {
  background-image: var(--image-from-somewhere);
}
.b::after {
  content: var(--image-embedded);
}

Cela vous permet de vous débarrasser des URL d'images longues et difficiles à manier et d'utiliser des noms de variables plus courts lorsque c'est nécessaire.

Abréviations

Une variable CSS peut être utilisée comme une valeur unique dans un raccourci, ou comme le racourci entier lui-même. Les deux éléments conteneurs ci-dessous auront le même padding.

:root {
  --top-padding: 60px;
  --all-padding: 60px 20px 40px 10px;
}
.container {
  padding: var(--top-padding) 20px 40px 10px;
}
.another-container {
  padding: var(--all-padding);
}

J'ai trouvé intéressant que les variables CSS puissent également contenir un segment partiel d'un raccourci formé de plusieurs valeurs.

Listes

Certaines propriétés, comme background et box-shadow, peuvent prendre une liste d'éléments. Vous pouvez utiliser une variable CSS comme un seul élément de la liste, une sous-liste de la liste ou la liste entière.

Voici quelques exemples de mélanges de listes box-shadow et de variables CSS. J'ai également glissé un exemple de mise en place d'une liste de couleurs dans une variable CSS pour l'utiliser dans un dégradé linéaire, car vous pouvez tout à fait le faire !

/*
  quick reminder of the anatomy of a box-shadow!
  box-shadow: <x-offset> <y-offset> <blur> <spread> <color>;
*/
:root {
  --single-shadow: 0 0 0 40px #355c7d;
  --multi-shadow: 0 0 0 60px #f67280, 0 0 0 80px #6c5b7b;
  --gradient-colors: #f1bbba, #ece5ce, #c5e0dc;
}
.a {
  box-shadow: 0 0 0 20px #60b99a, var(--single-shadow);
}
.b {
  box-shadow: var(--multi-shadow);
}
.c {
  box-shadow: 0 0 0 20px #60b99a, var(--single-shadow), var(
      --multi-shadow
    );
}
body {
  background-image: linear-gradient(45deg, var(--gradient-colors));
}

Et voici une démo pour voir ce que ça peut donner :

voirCSS Variables with Shadow Listsde lonekorean dansCodePen

Couleurs

Ah ! on ne peut pas oublier les couleurs ! Les variables CSS fonctionnent très bien pour les couleurs et il est très courant de les voir utilisées pour définir un thème de couleurs facile à consommer dans tout un site.

@media (prefers-color-scheme: light) {
  :root {
    --color-text: #233742;
    --color-links: #d80b77;
    --color-bg: white;
  }
}
@media (prefers-color-scheme: dark) {
  :root {
    --color-text: white;
    --color-links: #b4cddd;
    --color-bg: #233742;
  }
}
body {
  color: var(--color-text);
  background-color: var(--color-bg);
}
a {
  color: var(--color-links);
}

Vous pouvez également placer des valeurs de paramètres de couleur distinctes dans des variables CSS, puis les combiner en une couleur à l'aide de rgb()/rgba() et hsl()/hsla(). Voici un exemple utilisant rgb().

:root {
  --red: 216;
  --green: 11;
  --blue: 119;
}
a {
  color: rgb(var(--red), var(--green), var(--blue));
}

Réunir le tout avec l'animation

Peut-on mettre une valeur animée dans une variable CSS ? La réponse est : c'est compliqué !

Par défaut, la plupart du temps non. Certains navigateurs afficheront un seul saut discret de la valeur de départ à la valeur d'arrivée. D'autres navigateurs ne feront rien. Dans tous les cas, vous n'obtiendrez pas d'animation lisse et interpolée.

Le problème est que votre navigateur ne sait pas comment animer vos variables inventées. Mais bonne nouvelle ! Vous pouvez résoudre ce problème grâce à l'API Propriétés et Valeurs. Elle fait partie de Houdini et fonctionne actuellement dans Chrome, Edge et Opera, et d'autres navigateurs devraient suivre.

Voici comment cela fonctionne. Tout d'abord, déclarez vos propriétés personnalisées.

@property --red {
  syntax: '<integer>';
  inherits: true;
  initial-value: 0;
}
@property --green {
  syntax: '<integer>';
  inherits: true;
  initial-value: 0;
}
@property --blue {
  syntax: '<integer>';
  inherits: true;
  initial-value: 0;
}

Il s'agit de dire à votre navigateur "hé, voici quelques variables, ce sont des entiers qui ont la valeur 0 par défaut". Ensuite, votre navigateur peut dire "oh les entiers, super, je sais comment les animer". Et maintenant, nous sommes prêts pour l'animation.

@keyframes red-fade {
  50% {
    --red: 255;
  }
}
@keyframes green-fade {
  50% {
    --green: 255;
  }
}
@keyframes blue-fade {
  50% {
    --blue: 255;
  }
}
:root {
  animation: red-fade 16s, green-fade 14s, blue-fade 12s;
  animation-iteration-count: infinite;
}

Dans le CSS ci-dessus, il y a une animation keyframe pour chaque variable allant de 0 (la valeur initiale initial-value que nous avons déclarée) à 255 et inversement. Ces valeurs sont animées sur l'élément :root et tous les éléments enfants peuvent les utiliser car nous avons déclaré les variables avec inherits : true.

.swatch {
  background-color: rgb(var(--red), var(--green), var(--blue));
}

Et avec ça, nous avons 3 variables CSS animées indépendamment qui sont combinées ensemble via rgb() pour créer une background-color en constante évolution. Pas de JavaScript. Super !

voirCSS Variables Color Animationde lonekorean dansCodePen

Il se passe en fait beaucoup de choses dans cette démo. De multiples animations sont alimentées par ce trio de variables CSS animées (--red, --green, --blue). Décomposons le tout.

Tout d'abord, la grande palette de couleurs RGB. Nous en avons déjà parlé.

Ensuite, les indicateurs qui montent et descendent au-dessus des barres de couleur. Ils sont positionnés en convertissant les variables CSS en valeurs px négatives. Par exemple, voici le rouge.

.red .indicator {
  transform: translateY(calc(var(--red) * -1px));
}

Troisièmement, les chiffres affichés sous les barres de couleur. Celui-ci est intéressant. Comme mentionné précédemment, vous pouvez utiliser content pour afficher des chaînes de caractères, mais cela ne fonctionnera pas avec nos variables entières. Cependant, les compteurs CSS fonctionnent avec des valeurs entières et peuvent être affichés tout comme une chaîne de caractères avec du contenu.

.red .value::before {
  /* in goes an integer variable */
  counter-reset: color-value var(--red);
  /* out comes a string-like counter value */
  content: counter(color-value);
}

En gros, nous abusons des compteurs CSS pour convertir un nombre entier en chaîne de caractères. Que du plaisir.

Valeurs à l'échelle du CSS

Les propriétés personnalisées suivent les mêmes règles que les propriétés intégrées en ce qui concerne la cascade et l'héritage. Vous pouvez utiliser les mêmes valeurs spéciales CSS que sont initial, inherit, unset et revert sur les variables CSS pour contrôler ce qui y est finalement placé.

Au revoir

Du point de vue de la syntaxe, les variables CSS sont "extrêmement permissives". Il y a certainement d'autres types de choses que vous pouvez y mettre que je n'ai pas spécifiquement couvertes, mais j'espère en avoir montré suffisamment pour vous donner une idée des possibilités. De plus, nous avons eu l'occasion de jouer avec des couleurs animées, donc c'était amusant.

La propriété CSS grid-template-areas permet de définir et de nommer les cellules (ou les zones de grille) d'un conteneur de grille CSS.

.grid-container {
  display: grid;
  grid-template-areas: 'header header' 'sidebar main';
}

Que fait le code ci-dessus ? Eh bien nous obtenons une grille de deux par deux dont la rangée supérieure réserve deux colonnes à une zone appelée "header". La rangée inférieure dispose également de deux colonnes, mais les réserve à des zones de la grille appelées respectivement sidebar et main.

Notre grille est créée et nous avons défini des zones de grille, mais il n'y a rien d'assigné encore à ces zones. Si nous voulons placer un élément dans une zone de la grille, nous devons le déclarer explicitement avec la propriété grid-area sur cet élément :

.grid-container {
  display: grid;
  grid-template-areas: 'header header' 'sidebar main';
}
.grid-header {
  grid-area: header;
}
.grid-sidebar {
  grid-area: sidebar;
}
.grid-content {
  grid-area: main;
}

Il faut garder à l'esprit qu'une zone de grille doit être soit une cellule unique dans le conteneur de la grille, soit un groupe de cellules adjacentes de forme rectangulaire. Tous les exemples suivants sont valables :

Mais nous ne pouvons pas former des zones de grille non rectangulaires. Donc, pas de chance si la zone que vous voulez définir a plutôt la forme d'un "T" ou d'un "L".

Syntaxe

grid-template-areas: none | string
Initial value: none
Applies to: grid containers
Inherited: no
Computed value: as specified, the keyword none or a list of string values
Animation type: discrete

Valeurs

/* Keyword value */
grid-template-areas: none;
/* <string> values */
grid-template-areas: 'col-1 col-2 col-3';
grid-template-areas: 'header header header' 'sidebar main main';
grid-template-areas:
  'header header header'
  'sidebar main main'
  '. footer footer';
/* Global values */
grid-template-areas: inherit;
grid-template-areas: initial;
grid-template-areas: revert;
grid-template-areas: unset;

none

C'est la valeur par défaut. Comme vous l'avez sans doute deviné, none signifie qu'aucune zone de grille nommée ni aucune piste de grille explicite n'est définie dans le conteneur de grille. Ça signifie également que les pistes de la grille sont générées implicitement et que leurs tailles sont définies par les propriétés grid-auto-columns et grid-auto-rows.

Il existe en fait une autre façon de créer des pistes de grille explicites qu'en utilisant grid-template-areas, et c'est d'utiliser les propriétés grid-template-columns et grid-template-rows à la place. Nous y reviendrons plus en détail dans la suite de cet article.

string

Une chaîne de caractères (string) peut être n'importe quel nom que l'on souhaite donner à une zone spécifique du modèle de grille. Ainsi, si vous avez une rangée supérieure dans votre conteneur de grille et que vous voulez que l'en-tête de votre mise en page s'y trouve, vous pouvez nommer la zone "en-tête" ou "page-top" ou littéralement ce que vous voulez. En fait, s'il y a plusieurs colonnes dans cette rangée, nous pouvons donner à chacune d'elles un nom différent.

.grid {
  grid-template-areas: 'logo menu utility-nav';
}

On remarque que la totalité de la rangée de trois colonnes de cet exemple est entre guillemets. C'est essentiel, car les grid-template-area entre guillemets indiquent une nouvelle rangée. Ainsi, si nous avons deux rangées, nous verrons deux groupes entre guillemets :

.grid {
  grid-template-areas: 'logo menu utility-nav' 'sidebar-1 content sidebar-2';
}

Mieux encore, nous pouvons améliorer la lisibilité en écrivant chaque rangée sur sa propre ligne :

.grid {
  grid-template-areas:
    'logo menu utility-nav'
    'sidebar-1 content sidebar-2';
}

La syntaxe des chaînes de caractères permet de couvrir ou de sauter des cellules dans le conteneur de la grille. Nous y reviendrons dans un instant.

Utilisation de base

Tout d'abord, définissons les zones de grille en utilisant la propriété grid-template-areas dans le conteneur de grille parent :

.grid {
  display: grid;
  grid-template-areas:
    'header header header'
    'sidebar main main'
    'footer footer footer';
}

Dans l'état actuel des choses, le conteneur de grille comporte des zones nommées, mais rien à l'intérieur. Pour y placer des éléments, nous devons assigner la zone de grille nommée à un élément en utilisant la propriété grid-area sur l'élément que nous plaçons :

header {
  grid-area: header;
}
aside {
  grid-area: sidebar;
}
main {
  grid-area: main;
}
footer {
  grid-area: footer;
}

Voici le résultat basé sur les zones du modèle de grille que nous avons définies sur le conteneur de grille parent :

Dimensionnement des zones nommées d'une grille

La taille des zones de la grille peut être définie à l'aide des propriétés grid-template-columns et grid-template-rows dans le conteneur de la grille parente.

Supposons que notre grille ait besoin de deux colonnes et que la deuxième colonne prenne deux fois plus d'espace que la première. Nous pouvons utiliser l'unité fraction (fr) pour cela :

.grid {
  display: grid;
  gap: 1rem;
  grid-template-columns: 1fr 2fr;
  grid-template-areas: 'sidebar main';
}

Il en va de même pour les rangées. Supposons maintenant que nous ayons besoin de la présentation suivante dans une grille de trois par trois :

Cette fois-ci, les première et troisième rangées ont la même hauteur fixe de 250 pixels, mais la rangée du milieu est dimensionnée de manière à occuper autant d'espace que le contenu en a besoin :

.grid {
  display: grid;
  gap: 1rem;
  grid-template-rows: 250px auto 250px;
  grid-template-areas:
    'header header header'
    'sidebar main main'
    'footer footer footer';
}

Si vous vous demandez ce qu'il se passe avec toutes ces zones de gabarit de grille nommées à plusieurs reprises, il s'agit de...

...cellules et rangées qui s'étendent

La répétition d'une zone nommée relie les cellules. Ainsi, si l'objectif est de créer une zone nommée "feature" et qu'elle occupe deux colonnes dans la rangée supérieure, nous pouvons faire quelque chose comme ceci :

/* Valid declaration */
grid-template-areas: 'feature feature widget';

Cool, et nous pouvons faire la même chose dans le sens vertical si la même zone nommée commence chaque ligne :

/* Valid declaration */
grid-template-areas:
  'feature aside widget-1'
  'feature aside widget-2';

Bien entendu, nous pouvons combiner les deux pour obtenir une zone de gabarit qui s'étend dans les deux directions :

/* Valid declaration */
grid-template-areas:
  'feature feature widget-1'
  'feature feature widget-2';

Comme indiqué précédemment, les zones de grille doivent être rectangulaires. Ça signifie que la variante suivante du dernier exemple n'est pas valable :

/* Invalid declaration */
grid-template-areas:
  'feature feature widget-1'
  'feature aside widget-2';

Nous pouvons créer des espaces (ou des "arrêts") entre les cellules

C'est possible en utilisant la notation point (.) :

grid-template-areas:
  "header header header"
  "sidebar main main"
  ". footer footer"; /* la 1ère cellule est vide */
}

Le nombre de points n'a pas d'importance. Nous aurions pu faire ceci à la place :

grid-template-areas:
  "header  header header"
  "sidebar main   main"
  "....... footer footer"; /* la 1ère cellule est vide */
}

Les deux déclarations créent la même grille :

Les espaces blancs sont un bon moyen de visualiser la grille

Les déclarations suivantes sont équivalentes, mais la seconde permet de mieux visualiser la structure de la grille, car nous utilisons des espaces vides pour aligner les noms :

grid-template-areas:
  'header header header'
  'sidebar main main'
  '. footer footer';
grid-template-areas:
  'header  header header'
  'sidebar main   main'
  '.       footer footer';

Si vous cherchez une autre façon de visualiser un conteneur de grille, Chris a une idée astucieuse pour le "dessiner" dans une sorte de format ASCII.

Les rangées doivent avoir le même nombre de colonnes

Toutes les listes doivent avoir le même nombre de valeurs, sinon la déclaration n'est pas valide.

/* ? */
grid-template-areas:
  'name name-2 name-3'
  'name name-2 name-3'
  'name name-2 name-3';
/* ? */
grid-template-areas:
  'header header'
  '. main'
  'footer footer';
/* ? */
grid-template-areas:
  'name name-2 name-3'
  'name name-2 name-3'
  'name name-3';

Utilisation de caractères Unicode pour les zones de grille nommées

Selon les spécifications, tout nom qui ne correspond pas à la syntaxe ident doit être échappé lorsqu'il est fait référence à cette zone par son nom dans d'autres propriétés. Par exemple, dans la déclaration suivante, le nom de la première zone commence par un chiffre et ne correspond donc pas à la syntaxe <ident> :

.grid {
  grid-template-areas: '1st b c';
}

La solution consiste à déclarer le code hexadécimal non échappé pour le chiffre 1. Dans ce cas, c'est U+0031, que nous échappons dans le CSS sous la forme \31st. C'est donc ce que nous utilisons pour affecter un élément à la zone de grille nommée :

.grid-item {
  grid-area: \31st;
}

Noms de rangées attribués implicitement

La définition des pistes avec la propriété grid-template-areas nous donne gratuitement des noms de lignes basés sur les noms attribués. C'est différent des propriétés grid-template-rows et grid-template-columns où nous devons fournir des noms de lignes lors de la définition des colonnes et des rangées. Ce n'est pas le cas de la propriété grid-template-areas, car elle prend les noms que nous lui fournissons et produit des noms de pistes pour nous.

Quatre lignes de grille sont créées pour chaque nom de zone de grille. Si nous avons une zone de grille nommée sidebar, nous obtenons deux paires de lignes de piste nommées sidebar-start et sidebar-end - une paire pour la direction de la colonne et une paire pour la direction de la rangée :

On peut se demander ce qui se passe si l'on définit explicitement les noms des pistes et que l'on utilise le même nom que celui que l'on obtiendrait s'ils étaient définis implicitement — par exemple, si l'on définit explicitement une ligne de grille nommée sidebar-start pour une sidebar nommée area. Eh bien en fait les deux lignes peuvent coexister et être affectées à des éléments différents. En d'autres termes, la valeur explicite reste valable et les deux lignes peuvent être utilisées.

Zones nommées implicitement

Une autre façon de nommer les zones de grille dans un conteneur de grille est de laisser CSS Grid les nommer implicitement pour nous lors de la configuration des noms de pistes dans les propriétés grid-template-columns et grid-template-rows.

Tout ce que nous avons à faire est de choisir un nom pour la zone de grille et d'y ajouter à la fin -start et -end pour les noms de pistes. Ici, par exemple, nous obtenons une zone de grille appelée sidebar sans même déclarer la propriété grid-template-areas :

.grid-container {
  display: grid;
  grid-template-columns: [sidebar-start] 250px [sidebar-end] 1fr;
}
aside {
  grid-area: sidebar;
}

Comme le montre l'exemple ci-dessus, bien qu'il n'y ait pas de propriété grid-template-areas pour définir explicitement une zone nommée "sidebar", cette zone peut toujours être référencée par les propriétés grid-placement telles que grid-area, grid-row, grid-column ou leurs équivalents en écriture développée.

Exemple : Disposition réactive du Saint Graal

Dans la démo suivante, nous utilisons la propriété grid-template-areas pour créer la fameuse mise en page Holy Grail avec CSS Grid :

voirHoly grail layout with CSS Gridde Mojtaba Seyedi dansCodePen

Cette mise en page doit son nom au fait qu'elle était extrêmement difficile à réaliser à l'époque où l'on utilisait des float pour les mises en page. Heureusement, nous disposons de CSS Grid pour rendre cette tâche presque triviale.

Tout d'abord, notre HTML :

<div class="grid">
  <header>Header</header>
  <main>Main Content</main>
  <aside class="left-sidebar">Left Sidebar</aside>
  <aside class="right-sidebar">Right Sidebar</aside>
  <footer>Footer</footer>
</div>

C'est assez simple jusqu'à présent, pas vrai ? Nous voulons que l'en-tête soit en haut, que le pied de page soit en bas et que le contenu principal soit dans l'une des trois colonnes de la rangée du milieu.

Nous pouvons configurer les grid template areas nommées en CSS, et étendre les rangées si nécessaire :

.container {
  grid-template-columns: 12rem auto 12rem;
  grid-template-areas:
    'header header header'
    'left-sidebar main right-sidebar'
    'footer footer footer';
}

Nous devons maintenant assigner chaque élément à une zone de grille nommée :

header {
  grid-area: header;
}
main {
  grid-area: main;
}
footer {
  grid-area: footer;
}
.left-sidebar {
  grid-area: left-sidebar;
}
.right-sidebar {
  grid-area: right-sidebar;
}

Et voilà, techniquement c'est terminé ! C'est vraiment tout ce qu'il y a à faire. Nous pouvons aller plus loin en empilant les zones de la grille verticalement par défaut, puis construire le Saint Graal sur des écrans plus grands où l'aspect est bien meilleur :

.container {
  display: grid;
  grid-template-areas:
    /* Chaque zone est une rangée */
    'header'
    'nav'
    'article'
    'sidebar'
    'footer';
}
@media (min-width: 600px) {
  .container {
    grid-template-columns: 12rem auto 12rem;
    grid-template-areas:
      /* Build the Holy Grail layout */
      'header header header'
      'nav article article'
      'sidebar article article'
      'footer footer footer';
  }
}

Voir aussi :

• Comprendre CSS Grid : Grid template areas, de Rachel Andrew
• CSS Grid : la différence entre grilles explicite et implicite, de Manuel Matuzovic

Il n'est que trop fréquent de voir un HTML incorrect utilisé pour les citations dans le balisage. Dans cet article, nous allons creuser tout cela, en examinant différentes cas et différentes balises HTML pour gérer ces situations.

Il y a trois éléments HTML majeurs impliqués dans les citations :

• <blockquote>
• <q>
• <cite>

Regardons ça de plus près.

Les blocs de citation

Les balises Blockquote sont utilisées pour distinguer le texte cité du reste du contenu. Mon professeur d'anglais de classe de seconde m'a fait entrer dans la tête que c'est ainsi qu'on devait distinguer toute citation de quatre lignes ou plus. La spécification HTML n'impose pas une telle exigence, mais tant que le texte est une citation et que vous souhaitez qu'il soit séparé du texte et des balises qui l'entourent, un bloc de citation est le choix sémantique à faire.

Par défaut, les navigateurs mettent en retrait les guillemets en ajoutant une marge de chaque côté.

voirThe Blockquote Tagde Undead Institute dansCodePen

En tant qu'élément de flux (càd un élément de "niveau bloc"), blockquote peut contenir d'autres éléments. Par exemple, nous pouvons y déposer des paragraphes sans problème :

<blockquote>
  <p></p>
  <p></p>
</blockquote>

Mais on pourrait aussi y mettre d'autres éléments, comme un titre ou une liste non ordonnée :

<blockquote>
  <h2></h2>
  <ul>
    <li></li>
    <li></li>
  </ul>
</blockquote>

Il est important de noter que les blocs de citation ne doivent être utilisés que pour les citations et non comme un élément décoratif dans un design. Cela facilite également l'accessibilité, car les utilisateurs de lecteurs d'écran peuvent sauter entre les blocs de citation. Un bloc de citation utilisé uniquement à des fins esthétiques pourrait vraiment dérouter ces utilisateurs. Si vous avez simplement besoin d'un élément décoratif qui ne correspond pas sémantiquement à cette notion, une div avec une classe est sans doute la meilleure solution.

blockquote,
.callout-block {
  /* Ils pourraient partager le style */
}

Citation avec Q

Les balises Q (<q>) sont destinées aux citations en ligne, ou ce que mon prof de seconde appellerait les citations de moins de quatre lignes. De nombreux navigateurs modernes ajouteront automatiquement des guillemets à la citation en tant que pseudo-éléments, mais vous aurez peut-être besoin d'une solution de secours pour les navigateurs plus anciens.

voirThe Q Tagde CSSTricks dansCodePen

Les bon vieux guillemets sont tout aussi valables pour les citations en ligne que l'élément <q>. Cependant, l'élément <q> a quelques avantages : il comprend un attribut cite, la gestion automatique des guillemets et la gestion automatique des niveaux de citation. Les éléments <q> ne doivent pas être utilisés pour le sarcasme (par exemple, "vous utiliseriez une balise <q> pour le sarcasme ?"), ou pour signifier un mot avec des guillemets expressifs (par exemple, "génial" est une description "exacte" de l'auteur). Mais si vous arrivez à trouver une balise pour les guillemets expressifs, faites-le moi savoir. Parce que ce serait "génial".

L'attribut de citation

Aussi bien les <q> que les blockquotes peuvent utiliser un attribut de citation (cite). Cet attribut contient une URL qui fournit un contexte et/ou une référence à l'objet cité. La spécification met un point d'honneur à dire que l'URL peut être entourée d'espaces. (Je ne suis pas sûr de la raison pour laquelle c'est souligné, les dieux du code sémantique ont leurs raisons).

<p>
  The officer left a note saying
  <q cite="https://johnrhea.com/summons"
    >You have been summoned to appear on the 4th day of January on
    charges of attempted reader bribery.</q
  >
</p>
.

Cet attribut cite n'est pas visible par l'utilisateur par défaut. Vous pourriez l'ajouter avec un soupçon de magie CSS comme la démo suivante. Vous pourriez même le bidouiller davantage pour que la citation apparaisse au survol.

voirAttributable citationsde CSSTricks dansCodePen

Aucune de ces options n'est particulièrement géniale. Si vous devez citer une source de manière à ce que les utilisateurs puissent la voir et y accéder, vous devez le faire en HTML et probablement avec l'élément <cite>, que nous aborderons ensuite.

L'élément de citation

La balise <cite> doit être utilisée pour référencer un travail créatif plutôt que l'auteur de la citation. En d'autres termes, ce n'est pas pour les citations. Voici les exemples tirés de la spécification :

<p>
  Mon livre préféré est <cite>The Reality Dysfunction</cite> de Peter
  F. Hamilton. Ma bande dessinée préférée est
  <cite>Pearls Before Swine</cite> de Stephan Pastis. Mon morceau
  préféré est <cite>Jive Samba</cite> par le Cannonball Adderley
  Sextet.
</p>

Voici un autre exemple :

voirCite This!de CSSTricks dansCodePen

Si l'auteur de cet article vous disait qu'il vous donnerait un cupcake, et que vous le <cite>z par son nom, ce serait sémantiquement incorrect. Ainsi, aucun cupcake ne changerait de main. Si vous citiez l'article dans lequel il vous a offert un cupcake, ce serait sémantiquement correct, mais comme l'auteur ne le ferait pas, vous n'auriez toujours pas de cupcake. Désolé.

Par défaut, les navigateurs mettent le contenu des balises de citation en italiques et il n'est pas nécessaire qu'un <q> ou <blockquote> soit présent pour utiliser l'élément de citation. Si vous voulez citer un livre ou un autre travail créatif, placez-le dans l'élément cite. Les divinités sémantiques vous feront un grand sourire pour ne pas avoir utilisé les éléments <i> ou <em>.

Mais où placer l'élément cite ? À l'intérieur ? À l'extérieur ? A l'envers ? Si on le met à l'intérieur du <blockquote> ou du <q>, on l'intègre à la citation. C'est interdit par la spécification pour cette raison précise.

<!-- C'est apparemment faux -->
<blockquote>
  Citation sur la distribution de cupcakes à partir d'un article
  <cite>L'article</cite>
</blockquote>

Le mettre à l'extérieur semble juste mauvais et nécessite également que vous ayez un élément englobant comme une <div> si vous vouliez les styliser ensemble.

<div class="need-to-style-together">
  <blockquote>
    Citation d'un article sur la distribution de cupcakes
  </blockquote>
  <cite>L'article</cite>
</div>

N.B. Si vous cherchez cette question sur Google, vous tomberez peut-être sur un article de HTML5 Doctor datant de 2013 qui contredit une grande partie de ce qui est exposé ici. Cela dit, chaque fois qu'il établit un lien vers les docs, ceux-ci sont en accord avec l'article que vous êtes en train de lire plutôt qu'avec l'article de HTML5 Doctor. Il est donc fort probable que la documentation ait changé depuis la rédaction de cet article.

Et l'élément figure ?

Une façon de baliser une citation — et d'une manière qui plaît aux divinités du code sémantique — est de placer la citation en bloc dans un élément figure. Ensuite, mettez l'élément cite et toute autre information sur l'auteur ou la citation dans une figcaption.

<figure class="quote">
  <blockquote>
    Mais les navigateurs Web ne sont pas comme les serveurs Web. Si
    votre code back-end devient si gros qu'il commence à s'exécuter
    notablement lentement, vous pouvez y injecter plus de puissance de
    calcul en mettant à l'échelle votre serveur. Ce n'est pas une
    option sur le front-end où vous n'avez pas vraiment un seul
    environnement d'exécution - vos utilisateurs finaux ont leur
    propre environnement d'exécution avec ses propres contraintes
    autour de la puissance de calcul et de la connectivité réseau.
  </blockquote>
  <figcaption>
    &mdash ; Jeremy Keith, <cite>Modèles mentaux</cite>
  </figcaption>
</figure>

Cela double le nombre d'éléments nécessaires, mais il y a plusieurs avantages :

• C'est sémantiquement correct pour les quatre éléments.
• Il vous permet à la fois d'inclure et d'encapsuler des informations sur l'auteur au-delà de la citation du nom de l'œuvre.
• Il vous offre un moyen facile de styliser la citation sans avoir recours aux divs, aux espaces ou à des expédients misérables.

voirIt Figures You'd Say Thatde CSSTricks dansCodePen

Rien de tout cela n'est pour le dialogue

Pas de <dialog> ! Ça c'est pour les modales qui veulent attirer l'attention.

Ni <blockquote>, ni <q>, ni <cite> ne doivent être utilisés pour le dialogue et les échanges similaires entre locuteurs. Si vous marquez un dialogue, vous pouvez utiliser ce qui vous semble le plus logique. Il n'y a pas de manière sémantique de le faire. Cela dit, la spécification suggère les balises <p> et la ponctuation avec les balises <span> ou <b> pour désigner le locuteur et les balises <i> pour marquer les indications scéniques.

Accessibilité des citations

D'après mes recherches, les lecteurs d'écran ne devraient pas avoir de problème pour comprendre les balises <q>, <blockquote> ou <cite> approuvées par la sémantique.

D'autres "façons" de "citer"

Vous pouvez ajouter des guillemets à un <blockquote> en utilisant des pseudo-éléments CSS. L'élément <q> est livré avec des guillemets intégrés, il n'est donc pas nécessaire de les ajouter, mais les ajouter en tant que pseudo-éléments peut être une solution de contournement pour les anciens navigateurs qui ne les ajoutent pas automatiquement. Vu c'est ainsi que les navigateurs modernes ajoutent les guillemets, on ne risque pas d'ajouter des guillemets en double. Les nouveaux navigateurs écraseront les pseudo-éléments par défaut, et les anciens navigateurs qui prennent en charge les pseudo-éléments ajouteront les guillemets.

Mais vous ne pouvez pas, comme je l'ai fait, supposer que ce qui précède vous donnera toujours des guillemets ouvrants et fermants intelligents. Même si la police prend en charge les guillemets intelligents, il arrive que des guillemets droits soient affichés. Pour être sûr, il est préférable d'utiliser la propriété CSS quotes pour améliorer l'intelligence de ces guillemets.

blockquote {
  quotes: '“' '”' '‘' '’';
}

voir"Quot-a-tizing" the blockquotede CSSTricks dansCodePen

Citation à plusieurs niveaux

Examinons maintenant les niveaux de citation. La balise <q> ajustera automatiquement les niveaux de citation.

Disons que vous êtes dans une région qui utilise la convention britannique d'utiliser des guillemets simples. Vous pourriez utiliser la règle des guillemets CSS pour placer les guillemets simples d'ouverture et de fermeture en premier dans la liste. Voici un exemple des deux méthodes :

voirQuote Within a Quotede CSSTricks dansCodePen

Il n'y a pas de limite à l'imbrication. Ces éléments <q> imbriqués pourraient même se trouver dans un bloc de citation qui se trouve à l'intérieur d'un autre bloc de citation.

Si vous ajoutez des guillemets à un bloc de citation, sachez que le blockquote ne modifie pas le niveau de citation comme le fait une balise <q>. Si vous vous attendez à avoir des guillemets à l'intérieur d'un blockquote, vous pouvez ajouter une règle de sélection descendante pour faire commencer les éléments <q> à l'intérieur d'un blockquote au niveau des guillemets simples (ou doubles si vous suivez les conventions britanniques).

blockquote q {
  quotes: '‘' '’' '“' '”';
}

Le dernier niveau de guillemets que vous avez mis se poursuivra à travers les niveaux de guillemets suivants. Pour utiliser la convention double, simple, double, simple..., ajoutez d'autres niveaux à la propriété de guillemets CSS.

q {
  quotes: '“' '”' '‘' '’' '“' '”' '‘' '’' '“' '”';
}

Ponctuation suspendue

De nombreux experts en typographie vous diront que le fait de suspendre les guillemets sur les blockquotes est plus esthétique (et ils ont raison). Dans le cas qui nous intéresse, la ponctuation suspendue ce sont des guillemets repoussés du texte de sorte que les caractères du texte s'alignent verticalement.

Avec CSS, une possibilité serait d'utiliser une valeur légèrement négative sur la propriété d'indentation du texte text-indent. L'indentation négative exacte varie selon la police, alors assurez-vous de vérifier l'espacement avec la police que vous utilisez.

blockquote {
  text-indent: -0.45em;
}

Il existe un moyen plus agréable de gérer cette situation en utilisant la propriété CSS hanging-punctuation. Elle n'est prise en charge que par Safari au moment de la rédaction de ce document, nous devrons donc l'améliorer progressivement :

/* Fallback */
blockquote {
  text-indent: -0.45em;
}
/* S'il y a un support, effacez le retrait et utilisez la propriété à la place */
@supports (hanging-punctuation: first) {
  blockquote {
    text-indent: 0;
    hanging-punctuation: first;
  }
}

L'utilisation de la ponctuation suspendue est préférable car elle est moins compliquée. Cela fonctionnera simplement quand cela sera possible.

voirHanging Your Punctuationde CSSTricks dansCodePen

Peut-on animer les guillemets ?

Mais bien sûr !

voirDancing Quotesde CSSTricks dansCodePen

Table des matières

• Le HTML sémantique est la base d'un Web véritablement accessible.
• ARIA est un polyfill pour la sémantique HTML
• JavaScript est impératif pour créer des composants interactifs personnalisés véritablement accessibles
• L'amélioration progressive est une stratégie inclusive de construction pour le Web
• Le design ne dicte pas toujours l'implémentation
• Ce n'est pas parce que c'est techniquement accessible que c'est inclusif
• En fin de compte, il s'agit toujours de l'utilisateur
• En cas de doute, demandez de l'aide
• Derniers mots

(Cet article a été initialement publié sur 24 accessibilité).

Il y a quelques années, je ne savais pas ce que signifiait le terme "accessibilité". J'ai construit des sites Web qui étaient partiellement inaccessibles parce que je ne savais pas mieux. Aujourd'hui, j'en sais assez pour écrire, parler et animer des ateliers sur l'accessibilité, afin d'aider les autres à créer un Web plus accessible et inclusif. Comme tout le monde dans notre domaine, j'apprends encore. Mais depuis que j'ai commencé, j'ai appris beaucoup de leçons précieuses et de valeurs fondamentales qui guident mon travail aujourd'hui. En voici quelques-unes.

Le HTML sémantique est le fondement d'un Web véritablement accessible

Le HTML est sémantique, ou en d'autres termes, il est descriptif et donne du sens — chaque élément HTML décrit le type de contenu qu'il présente. Ainsi, si vous avez un titre, vous utilisez un élément de titre. Si vous avez un paragraphe, vous utilisez une balise <p>. En d'autres termes, il s'agit d'utiliser les bons éléments HTML pour leur objectif correct.

En utilisant les éléments corrects, le contenu de votre document aura une structure et un sens transmissibles.

La structure est importante car elle favorise l'interopérabilité. L'interopérabilité est la capacité de différents systèmes, dispositifs, applications ou produits à se connecter et à communiquer de manière coordonnée, sans effort de la part de l'utilisateur final. En d'autres termes, elle permet à davantage de dispositifs d'interpréter et d'accéder à votre contenu, y compris aux dispositifs qui apparaîtront dans le futur.

La structure aide les applications telles que les applications de lecture et les modes de lecture (comme le mode de lecture de Safari) ainsi que les environnements tels que le mode de contraste élevé de Windows à comprendre votre contenu et à le styliser de manière à améliorer l'expérience utilisateur. Cela n'est possible que lorsque les éléments sémantiques HTML appropriés sont utilisés, tels que <article>, <h1>, <ul>, <aside>, <nav>, parmi de nombreux autres disponibles dans HTML5. Ces éléments décrivent le type de contenu qu'ils contiennent. Sans eux, ces applications ne seraient pas en mesure de dire ce qu'est ce contenu, et ne pourront donc pas le styliser correctement. Cela augmente le risque de rendre le contenu moins accessible, voire complètement inaccessible.

La structure est également importante du fait qu'elle permet à vos utilisateurs de naviguer plus efficacement dans votre contenu. Les utilisateurs de lecteurs d'écran s'appuient sur une structure de document appropriée pour accéder plus rapidement aux zones de la page dont ils ont besoin. Pour ce faire, ils utilisent diverses touches de raccourci — des commandes puissantes mais destinées aux utilisateurs de lecteurs d'écran. Si vous n'utilisez pas de points de repère appropriés (exposés aux lecteurs d'écran via des éléments HTML sémantiques tels que <nav> et <main> et <header>), les utilisateurs de lecteurs d'écran risquent de ne pas pouvoir naviguer efficacement dans la page et devront rechercher leurs centres d'intérêt de manière plus fastidieuse.

La sémantique véhicule également un objectif. Les éléments HTML, comme le dit Jeremy Keith dans son livre Web "Resilient Web Design", sont un vocabulaire de signification. Lorsque vous utilisez partout les bons éléments HTML, cela permet à différentes applications et appareils de transmettre la signification de votre contenu à l'utilisateur afin qu'il sache ce qu'il doit en attendre et comment interagir avec lui.

Par exemple, lorsque vous utilisez <button> pour créer un bouton, un lecteur d'écran expose ce bouton comme ce qu'il est, et l'utilisateur sait qu'il peut effectuer une action spécifique à l'aide de ce bouton (généralement spécifié à l'aide du nom accessible du bouton) en appuyant sur la touche ESPACE ou sur la touche ENTRÉE. L'élément natif <button> est livré avec toutes les fonctionnalités et l'accessibilité intégrées par défaut.

Mais si vous n'utilisez pas un <button> pour créer un bouton, et que vous choisissez d'utiliser une <div>, par exemple, à la place, vous perdez toute la sémantique intégrée et l'interactivité du clavier, ce qui rend le bouton complètement inaccessible aux lecteurs d'écran.

"Mais vous pouvez utiliser les attributs ARIA pour transformer un div en bouton ! N'est-ce pas ?"

Eh bien, oui et non...

ARIA est un polyfill pour la sémantique HTML

La première règle de l'ARIA est la suivante :

Cependant, même si nous devons privilégier l'utilisation d'éléments HTML natifs chaque fois que possible, il existe certains widgets que nous ne pouvons construire qu'avec l'aide d'ARIA. Par exemple, il n'existe pas d'équivalent HTML natif pour les widgets d'onglet (par exemple, le balisage composé de role=tab, tablist et tabpanel) — avec toute l'interactivité intégrée par défaut, nous pouvons donc créer des onglets en réaffectant d'autres éléments avec ARIA et en les exposant combinés sous forme d'interface utilisateur à onglets aux utilisateurs de lecteurs d'écran (par exemple, role="tab", role="tablist", etc.)

Du fait que l'ARIA modifie fondamentalement la sémantique exposée et les mappages d'accessibilité des éléments, s'il est mal utilisé, il peut avoir des répercussions négatives sur la façon dont le contenu est exposé aux personnes utilisant des technologies d'assistance. Scott O'Hara, se référant aux ARIA Practices Guidelines note :

Avant d'utiliser les attributs ARIA, réfléchissez à ce que vous promettez à vos utilisateurs. Les attributs ARIA affectent directement la manière dont les éléments sont exposés dans l'arbre d'accessibilité, et donc la manière dont ils sont communiqués à vos utilisateurs. Utilisez-les avec sagesse et parcimonie, et assurez-vous que ce que vous avez construit répond aux attentes que vous avez créées pour vos utilisateurs. Si vous avez besoin d'indications sur la façon de les utiliser et de ne pas les utiliser, le document Using ARIA est un excellent point de départ.

JavaScript est impératif pour créer des composants interactifs personnalisés réellement accessibles

Même s'il est possible de créer des composants interactifs "fonctionnels" tels qu'une ouverture de modale en CSS uniquement, ou un widget de divulgation (disclosure widget) à l'aide du fameux hack de la case à cocher, il est presque toujours garanti que ces composants en CSS uniquement ne sont pas réellement accessibles.

Lorsque vous créez un widget interactif, il est fort probable que ce widget ait un état (state). Un widget de divulgation est soit "ouvert", soit "fermé" (ou "déployé/rétracté"). Cet état est exposé aux utilisateurs de lecteurs d'écran à l'aide d'attributs ARIA (par exemple, aria-expanded="true/false), et lorsqu'un utilisateur interagit avec le widget, l'état change, et ce changement doit être transmis à l'utilisateur. JavaScript est nécessaire pour ce faire. J'ai fait la paix avec ce fait il y a deux ans lorsque j'ai dû créer une infobulle accessible pour l'un de mes clients.

JavaScript est également nécessaire pour ajouter des fonctionnalités de clavier à des composants personnalisés (par exemple, les onglets d'une interface à onglets doivent être nagivables par les touches fléchées, et un widget de divulgation doit pouvoir être utilisé à l'aide des touches ESPACE et ENTRÉE).

Remarque : même si JavaScript est obligatoire pour créer des composants interactifs personnalisés, afin de vous assurer que votre contenu est accessible à tous les utilisateurs quel que soit leur contexte, vous pouvez, et devriez probablement, dans la mesure du possible, vous assurer qu'ils peuvent consommer ce contenu lorsque JavaScript n'est pas disponible. En fait, vous ne devriez jamais supposer que vos utilisateurs disposeront de JavaScript, car ils pouraient avoir bien des raisons de ne pas en disposer. C'est pourquoi l'amélioration progressive est la stratégie la plus accessible pour construire pour le Web. J'irais même jusqu'à dire que c'est une exigence, dans certains cas, pour créer des documents et des composants inclusifs.

L'enrichissement progressif est une stratégie inclusive pour la construction du Web

De nombreux développeurs semblent croire, à tort, que si JavaScript est nécessaire pour rendre un composant interactif accessible, alors il est impossible de le construire en utilisant l'amélioration progressive comme approche. Ces développeurs pensent que l'amélioration progressive est anti-JavaScript. C'est une erreur.

L'amélioration progressive consiste à superposer des couches, en commençant par la base la plus résistante — le HTML sémantique ! — puis en y superposant les styles (CSS) et les fonctionnalités (JavaScript !) selon les besoins.

L'amélioration progressive permet d'avoir une couche résiliente de contenu qui sera toujours accessible, même si le CSS et/ou le JavaScript sont absents.

Du jour où j'ai découvert l'amélioration progressive, c'est devenu ma stratégie de prédilection pour la création d'interfaces Web. Je ne peux pas imaginer créer pour le Web d'une autre manière. Et quand j'ai commencé à construire en tenant compte de l'accessibilité, j'ai été convaincue qu'il s'agissait de l'approche la plus sensée pour développer pour le Web.

Prenons à nouveau l'exemple d'un composant à onglets. Dans un tel composant, vous avez une série d'onglets qui contrôlent leurs panneaux de contenu respectifs. L'utilisateur peut naviguer entre ces panneaux en cliquant sur l'onglet qu'il souhaite. Les onglets nécessitent JavaScript pour être opérationnels et accessibles. Mais que se passe-t-il si JavaScript ne fonctionne pas ? Si les onglets n'ont pas été "améliorés progressivement" — s'ils ont été construits en partant du principe que JavaScript serait toujours présent, alors le composant ne fonctionnera pas et le contenu de tous les panneaux cachés sera totalement inaccessible.

Mais si vous envisagez ces onglets du point de vue de l'amélioration progressive, vous devrez considérer à quoi ressemblerait leur contenu s'ils avaient été créés uniquement à l'aide de HTML — sans le CSS qui permet de comprendre et d'utiliser l'interface à onglets, et sans le JavaScript qui les fait se comporter comme des onglets typiques.

Vous pouvez alors considérer les onglets et les panneaux comme une série de sections, chacune ayant un titre et un contenu. Ces sections peuvent avoir ou non une table des matières en haut. Il s'agit de la "vue" par défaut, et c'est ce que l'utilisateur obtient par défaut lorsque le JavaScript ne fonctionne pas.

Ensuite, lorsque le JavaScript s'exécute, vous pouvez améliorer ces sections en modifiant leur disposition et leur affichage, et en ajoutant l'interactivité requise. La façon dont je procéderais est que j'ajouterais probablement un hook de style que je souhaite dans le balisage, puis je l'utiliserais pour modifier la disposition de mes sections en sachant que le JavaScript a été exécuté et que les onglets seront exploitables et interactifs.

Lorsque vous déplacez l'accessibilité à gauche de votre processus, l'utilisation de l'amélioration progressive comme stratégie de développement prend encore plus de sens. Pratiquement tous les composants interactifs non natifs que j'ai construits au cours de l'année écoulée ont été améliorés à partir d'un composant non interactif de base. Commencez par HTMl. Utilisez tout ce qu'il a à offrir pour fournir une expérience de base accessible. Améliorez ensuite avec CSS et JavaScript lorsqu'ils sont disponibles.

L'une des façons les plus courantes de démolir la sémantique est de la dériver du design visuel. Car le design visuel ne décrit pas toujours le type de contenu qu'elle représente.

Les titres en sont un parfait exemple. Lors d'une récente conférence, j'ai montré un exemple tiré de l'un de mes derniers projets client, où la page était conçue de telle manière qu'un titre principal pour la page était apparemment inexistant, alors qu'en fait il ne l'était pas. Il n'était simplement pas stylisé comme le serait normalement un grand titre de niveau 1.

En réfléchissant à la structure du document et aux attentes des utilisateurs de lecteurs d'écran, je savais que la page devait avoir un titre principal. J'avais dû fournir un titre pour les utilisateurs de lecteurs d'écran pour certaines autres pages où un titre était visuellement absent mais, dans ce cas particulier, le titre était déjà là, il était juste stylisé pour avoir une apparence différente. Il semblait donc que la page n'avait pas de titre principal, mais en réalité elle en avait un.

En regardant la page du point de vue de l'accessibilité et en gardant à l'esprit la couche HTML — sémantique et structure, j'ai changé ma façon de voir la page, et j'ai fondamentalement changé la façon dont j'ai fini par la coder.

L'apparence d'un composant ou d'un élément ne dit pas ce qu'il l'est. Et ce n'est pas parce qu'il n'a pas une certaine apparence qu'il n'est pas ce qu'il est.

Il en va de même pour les modèles d'interface utilisateur interactive. Le même modèle peut créer une expérience différente selon le contexte dans lequel il se trouve. Souvent, le contexte définit le comportement d'un modèle, l'expérience de l'utilisateur, ce qui, à son tour, détermine la sémantique sous-jacente et l'implémentation.

Dans ce même projet que je viens de mentionner, il y avait un modèle d'interface utilisateur apparemment simple qui s'est avéré être un défi intéressant pour l'UX et l'accessibilité. L'image suivante est une capture d'écran de ce composant :

Pour implémenter ce lecteur vidéo, j'avais besoin de savoir comment il fonctionnait, afin de pouvoir le baliser de manière à transmettre correctement sa sémantique et sa fonctionnalité aux lecteurs d'écran.

Même si la liste de titres de vidéos sur la droite ressemble à une liste de liens, ce n'est pas vraiment une liste, ni même des liens, car un lien est censé vous mener quelque part, mais ces "liens" ne le font pas. En fait, en cliquant sur un titre de vidéo, celle-ci est chargée dans le lecteur de gauche. Il s'agit donc d'un élément interactif qui effectue une action et qui n'est pas un lien. Par conséquent, et même si leur apparence ne le montre pas, ces titres sont en fait des boutons.

Ensuite, il y avait la question de savoir ce qui se passe lorsqu'on clique sur un titre. La vidéo se met-elle en lecture automatique ? Si c'est le cas, alors le bouton devrait probablement aussi mettre la vidéo en pause, ce qui en fait une sorte de bouton à bascule (toggle). Mais si vous lancez ou mettez en pause une vidéo à partir du bouton de titre, vous devriez associer ce bouton aux boutons de lecture/pause dans la vidéo elle-même, ce qui peut être un défi, car la vidéo pourrait être une vidéo Youtube, ou Vimeo, ou auto-hébergée. Et si vous ne faites pas de lecture automatique de la vidéo, devez-vous déplacer le focus vers l'iframe après avoir cliqué sur le bouton ?

Après avoir examiné l'interface utilisateur prévue et testé avec des lecteurs d'écran, j'ai fini par l'implémenter en tant que composant à onglets, tous les onglets contrôlant le seul panneau contenant la vidéo.

Je n'avais jamais pensé à une interface à onglets avec plusieurs onglets contrôlant le même panneau auparavant. Mais le contexte de ce composant et l'UX de celui-ci ont déclenché un train de pensées et de considérations UX qui ont conduit à l'implémentation finale.

L'une des choses que j'ai apprises de ce composant est donc que l'expérience utilisateur (UX) détermine la mise en œuvre. ARIA est livré avec de nombreux attributs qui nous permettent de créer différents modèles d'interface utilisateur dans différents contextes, et parfois, il suffit de modifier un peu le modèle pour qu'il fonctionne dans le contexte dans lequel il se trouve.

Ce n'est pas parce que c'est techniquement accessible que c'est inclusif

Vous pouvez construire quelque chose de techniquement accessible mais qui n'en est pas pour autant inclusif. Cet élément ou ce composant peut avoir tous les boutons que vous voulez et vous pouvez peut-être y naviguer à l'aide d'un clavier et l'utiliser avec un lecteur d'écran, mais avez-vous vraiment pris en compte les besoins et les attentes de votre utilisateur lorsque vous avez décidé comment et avec quoi cet élément devait être exposé et interagir ?

Dans sa présentation "Inclusive by Design", Derek Featherstone, défenseur de l'accessibilité et designer, raconte comment lui et son équipe ont construit un lecteur vidéo accessible pour une organisation qui leur avait passé un contrat. Le lecteur vidéo comportait de nombreux boutons et son accessibilité technique a été testée au cours de nombreuses phases.

Mais lorsque le moment est venu de faire tester le composant par des utilisateurs souffrant de différents handicaps, ils ont réalisé que, même s'ils avaient construit le lecteur vidéo accessible parfait, ce lecteur vidéo n'était pas vraiment inclusif — il lui manquait certaines fonctionnalités qui facilitaient l'utilisation du lecteur pour un groupe d'utilisateurs, comme un bouton de retour en arrière ou d'avance rapide. Derek et son équipe avaient également fait des hypothèses sur la façon dont tous les utilisateurs utiliseraient le lecteur vidéo, et avaient oublié les utilisateurs qui connaissaient une ancienne version d'un lecteur d'écran et qui manquaient donc des annonces importantes, censées les aider à utiliser le lecteur vidéo. Ainsi, après plusieurs itérations et tests avec divers utilisateurs, ils ont fini par ajouter des fonctionnalités au lecteur vidéo qui prenaient en compte beaucoup plus de handicaps, et les attentes que ces utilisateurs auraient du lecteur, ce qui l'a rendu beaucoup plus inclusif et a énormément amélioré son expérience utilisateur.

L'exposé de Derek est rempli de bons exemples qui soulignent l'importance d'inclure vos utilisateurs dès le début du processus de conception et de veiller à ce que vous adoptiez la diversité par défaut. L'idée est que si vous concevez quelque chose pour moi, je devrais avoir un moyen raisonnablement significatif de participer à cette chose. Je devrais y être représenté d'une manière ou d'une autre.

En fin de compte, il s'agit toujours de l'utilisateur

À mesure que vous développez en tenant compte des expériences réelles des utilisateurs et de l'inclusivité, vous vous rendrez vite compte qu'un pattern de design peut être construit de plus d'une façon. Et il y a pas mal d'éléments dans la conception accessible qui sont le résultat d'une opinion.

Les fenêtres modales en sont un excellent exemple. Passons sur le fait qu'il s'agit d'un pattern d'interface utilisateur ennuyeux, la façon dont ils doivent être mis en œuvre et le comportement qu'ils doivent adopter une fois ouverts font l'objet de nombreuses discussions : Faut-il mettre le focus sur le premier élément focalisable à l'intérieur de la modale ? Que se passe-t-il s'il n'y a pas d'élément focalisable ? Que se passe-t-il si le premier élément focalisable est le bouton de fermeture ? Voudriez-vous que l'ouverture de la modale invite à une action de fermeture dès qu'elle est ouverte ? (bien sûr que non). Que se passe-t-il si le premier élément focalisable est un champ de saisie demandant à l'utilisateur son adresse électronique ? Est-il approprié d'inviter l'utilisateur à fournir ses informations personnelles sans contexte préalable ? (Là encore, bien entendu, non.)

En fin de compte, quelle que soit la décision que vous prenez, elle doit toujours concerner l'utilisateur. Il est donc essentiel d'impliquer l'utilisateur et/ou une équipe plus diversifiée dans le processus de design et de développement pour créer des interfaces Web véritablement inclusives.

Mais que faire si vous ne pouvez pas ? Et si vous n'avez pas accès à un tel environnement ou à une telle équipe ? Et si, comme moi, vous êtes un développeur solitaire qui rejoint souvent des équipes dans lesquelles ne participent généralement pas d'utilisateurs ou de personnes handicapées ?

En cas de doute, demandez de l'aide

Si vous ne pouvez pas le faire vous-même, vous pouvez demander l'expérience et les conseils d'autres personnes qui le peuvent. Et il est très important que vous soyez ouvert aux commentaires constructifs.

Il existe dans notre domaine un grand nombre de merveilleux (et parfois grincheux, à juste titre) experts en accessibilité qui veulent que le Web soit et devienne plus accessible. La plupart d'entre eux font un travail gratuit comme donner des conseils gratuits et partager leurs précieuses connaissances sous diverses formes écrire des articles et des livres, réaliser des cours vidéo, donner des conférences et des ateliers, etc. Et nous pouvons apprendre beaucoup d'eux. Et la plupart d'entre eux accueillent volontiers les questions et les demandes (payantes ou non).

Certains de mes experts préférés sont (sans ordre particulier) :

• Leonie Watson
• Derek Featherstone
• Scott O'Hara
• Marcy Sutton
• Rob Dodson
• Alice Boxhall
• Eric Bailey
• Steve Faulkner
• Le groupe Paciello

Il serait bon de passer un peu de temps à lire les spécifications et les lignes directrices ARIA, et d'essayer de vous familiariser avec autant de choses que possible sur l'accessibilité, avant de demander de l'aide. Après tout, ces personnes bienveillantes sont peut-être en mesure de nous aider, mais elles ne devraient pas avoir à faire notre travail à notre place — du moins pas gratuitement.

Derniers mots

L'accessibilité n'est pas facile. Et souvent, elle est carrément difficile. Mais cela vient avec le territoire. Concevoir pour les humains est difficile. Et l'accessibilité est, en fin de compte, tout sur et tout pour les humains.

Il se peut que nous n'y arrivions pas complètement et qu'il y ait toujours moyen de s'améliorer, surtout si davantage d'utilisateurs se servent de nos produits et consomment notre contenu, mais je sais une chose : cela ne doit jamais nous décourager. Presque tout peut être amélioré d'une manière ou d'une autre. Le plus important est d'être ouvert aux commentaires et d'être suffisamment empathique pour se soucier de nos utilisateurs et faire de notre mieux pour leur faciliter la vie avec les outils (puissants) que nous avons à notre disposition.

Utilisez le HTML. Améliorez avec CSS. Exploitez la puissance de JavaScript. Et incluez vos utilisateurs dans votre processus de conception le plus tôt possible. Et regardez toujours votre travail à travers le prisme de l'inclusion. Cela vous mènera loin devant. Alors apprenez davantage, itérez et améliorez. Et n'oubliez pas que nous sommes tous temporairement valides.

L'utilisation de la pseudo-classe :has() nous permet de "regarder en avant" avec CSS et de styliser un élément parent ou ancêtre. Nous pouvons ensuite élargir le sélecteur pour cibler un ou plusieurs éléments frères ou enfants. En utilisant l'état ou la position des éléments, nous pouvons styliser pratiquement n'importe quelle combinaison d'éléments comme des éléments uniques ou des plages.

La compatibilité de :has() s'améliore rapidement, :has() est disponible depuis Safari 15.4 et Chrome/Edge 105. Elle se cache également derrière un drapeau dans Firefox à partir de la version 103. Jusqu'à ce que la prise en charge complète soit disponible, consultez ce conseil de Bramus Van Damme sur la prise en charge de :has() aujourd'hui.

Comment :has() fonctionne avec les combinateurs et les pseudo-classes

Pour mieux comprendre le fonctionnement des sélecteurs avancés que nous allons créer, nous allons passer rapidement en revue les combinateurs et les pseudo-classes les plus pertinents.

Un "combinateur" est un caractère spécial qui désigne le type de relation entre les parties du sélecteur. Voici les principaux combinateurs à connaître :

• caractère espace : le combinateur descendant correspond à un enfant direct ou imbriqué ;
• > : le combinateur d'enfant direct correspond uniquement aux enfants de niveau supérieur, non imbriqués ;
• + : le combinateur de frère ou sœur adjacent(e) ne correspond qu'au frère ou sœur le plus proche ;
• ~ : le combinateur sibling général correspond à un ou plusieurs frères et sœurs suivant le sélecteur de base.

La première étape de la création de sélecteurs complexes consiste à ajouter une pseudo-classe en une ou plusieurs parties. Une "pseudo-classe" définit un état spécial d'un élément, comme :hover, et a le format d'un simple deux-points suivi du nom. La pseudo-classe :has() est appelée fonctionnelle car elle accepte un argument. Plus précisément, elle accepte comme argument une liste de sélecteurs, qu'ils soient simples comme img ou complexes avec des combinateurs comme img + p.

:has() est l'une des quatre pseudo-classes fonctionnelles, les autres étant :is(), :where() et :not(). Chacune prend une liste de sélecteurs ainsi que quelques autres caractéristiques uniques.

Si vous avez déjà utilisé :is() et :where(), c'était probablement pour gérer la spécificité. L'utilisation de :is() signifie que le sélecteur de la liste ayant la spécificité la plus élevée donne son poids à l'ensemble du sélecteur. L'utilisation de :where() quant à elle confère à l'ensemble de la liste de sélecteurs une spécificité nulle, ce qui permet aux règles ultérieures de la cascade de l'ignorer.

Par ailleurs, :is() et :where() ont la capacité spéciale d'être des sélecteurs indulgents, ce qui signifie que vous pouvez inclure (volontairement ou non) des sélecteurs que le navigateur ne comprend pas, et il traitera quand même les parties qu'il comprend. Sans ce comportement indulgent, le navigateur rejetterait la règle entière.

L'autre avantage de :is() et de :where() est de créer des sélecteurs succincts et complexes. C'est particulièrement pratique lorsque vous utilisez des combinateurs et que vous affectez plusieurs frères et sœurs ou descendants, par exemple, article :is(h1, h2, h3).

Notre dernière pseudo-classe, :not(), est disponible depuis plus longtemps. Toutefois, parallèlement aux sélecteurs de niveau 4, lorsque :is() et :where() ont été publiés, :not() a été améliorée. Elle a été autorisée à accepter une liste de sélecteurs au lieu d'un seul sélecteur. Elle a également le même comportement de spécificité que :is().

Enfin, nous devons connaître une fonctionnalité sous-utilisée et incroyablement puissante de :is(), :where() et :not(), que nous utiliserons pour créer nos sélecteurs :has() avancés. L'utilisation du caractère * dans ces sélecteurs — qui, normalement, en CSS, est le "sélecteur universel" — fait référence à la cible du sélecteur. Cela permet de vérifier les frères et sœurs ou les ancêtres précédents de la cible du sélecteur. Par exemple, dans img:not(h1 + *), nous sélectionnons les images qui ne suivent pas directement un h1. Et dans p:is(h2 + *), nous sélectionnons les paragraphes uniquement s'ils suivent directement un h2. Nous allons utiliser ce comportement pour notre première démo à venir.

Polyfill pour le sélecteur :only-of-type

:only-of-type est une pseudo-classe valide, (NdT : elle est décrite ainsi dans MDN : La pseudo-classe :only-of-type permet de cibler un élément qui ne possède aucun nœud frère du même type au sein d'un même élément parent). À partir du HTML ci-dessous...

<p>Not highlighted</p>
<p class="highlight">.highlight</p>
<p>Not highlighted</p>

...avec le CSS .highlight:only-of-type, aucune correspondance ne serait faite parce que la classe n'a aucun effet sur la réduction de la portée (scope).

Si le paragraphe porteur de la classe highlight était le seul paragraphe à l'intérieur de son parent, on pourrait croire que ça fonctionne. Mais ce serait une illusion car, dans ce cas, ce serait uniquement parce que le type d'élément racine auquel la classe est attachée est un paragraphe, donc il correspond comme vrai puisqu'il n'y a pas de paragraphes frères.

:has nous permet de résoudre ce problème. En combinant :has() et :not(), nous pouvons effectivement créer un sélecteur :only-of-selector qui fera correspondre un singleton dans une plage de frères et sœurs basée sur une classe ou un autre sélecteur valide.

En fin de compte, nous voulons que notre sélecteur trouve une correspondance lorsqu'il n'existe aucun frère ou sœur correspondant avant ou après la cible.

Une force de :has() est de tester ce qui suit un élément. Ici, nous voulons tester un nombre quelconque de frères et sœurs qui suivent, nous utiliserons donc le combinateur général de frères et sœurs ~ pour créer la première condition.

.highlight:not(:has(~ .highlight)

Jusqu'à présent, cela nous donne la correspondance de "classe highlight qui n'a pas de classe highlight sœur qui la suit".

Maintenant, nous devons vérifier les frères et sœurs précédents, et nous allons utiliser la capacité de :not() pour ajouter cette condition.

.highlight:not(:has(~ .highlight)):not(.highlight ~ *)

La deuxième condition :not() ajoute une clause ET à notre sélecteur qui dit "ET pas lui-même un frère ou une sœur d'une highlight précédente".

Avec cela, nous avons polyfillé la pseudo-classe inexistante :only-of-selector !

voir:only-of-selector using :has()de smashingmag dansCodePen

Sélecteur de frères et sœurs précédents

Nous avons parlé de la vérification des frères et sœurs précédents avec :not(), :is() et :where(). Avec :has(), nous pouvons en fait sélectionner et styliser les frères et sœurs précédents en fonction des conditions de ce qui vient après eux !

Pour démontrer cela, nous allons créer une liste d'éléments. Le comportement que nous souhaitons est le suivant : lorsqu'un élément de la liste est survolé, il s'agrandit et les éléments qui le précèdent et le suivent s'agrandissent également légèrement. Les autres éléments de liste non survolés doivent être réduits. L'opacité de tous les éléments de la liste, à l'exception de l'élément survolé, doit également être réduite. La vidéo suivante présente un aperçu de l'effet.

Previous/next list preview from Smashing Magazine on Vimeo.

Le premier sélecteur doit correspondre à l'élément de la liste qui précède celui qui est survolé, ce que :has() rend possible. Le CSS qui suit se lit : "sélectionner l'élément liste dont le frère adjacent est survolé".

li: has(+ li: hover);

Nous allons coupler cela avec un sélecteur de base de frère ou sœur adjacent pour obtenir également l'élément liste suivant celui qui est survolé, puis appliquer nos styles :

/* Sélectionne l'élément liste avant celui qui est survolé */
li:has(+ li:hover),
/* Sélectionner l'élément liste après l'élément survolé */
li:hover + li {
  /* ...modifier l'échelle et l'opacité */
}

Le troisième sélecteur complexe que nous allons créer utilise notre combinaison de :has() et :not() mais d'une nouvelle manière. Nous qualifions d'abord le sélecteur pour qu'il ne s'applique que lorsqu'un enfant direct de l'ul (qui sera un élément liste) est survolé. Et si c'est le cas, nous sélectionnons les éléments de la liste en excluant celui qui est survolé et les éléments avant et après celui qui est survolé.

/* Lorsqu'un élément de liste est survolé,
sélectionner les éléments de la liste non survolés, ou avant/après le survol */
ul:has(> :hover) li:not(:hover, :has(+ :hover), li:hover + *) {
  /* ...modifier l'échelle et l'opacité */
}

voirPrevious/Next Sibling Animation with :has()de smashingmag dansCodePen

Ceci nous montre non seulement la sélection d'un frère ou d'une sœur précédent(e) avec :has() mais aussi son utilisation pour sélectionner en fonction de l'état (state). La démo finale créera un exemple plus complexe en utilisant les états avec :has().

D'autres personnes ont exploré des exemples similaires de sélection et d'application de frères et sœurs précédents, notamment Chris Coyier, pourya et Jim Nielsen.

Sélection à l'intérieur d'une plage

Considérons maintenant une plage d'éléments frères et sœurs, comme entre h2 ou entre hr.

<article>
  <h2>Lorem, ipsum.</h2>
  <!-- h2 range starts -->
  <p>Lorem ipsum, dolor sit amet consectetur adipisicing elit.</p>
  <p>
    Nobis iusto voluptates reiciendis molestias, illo inventore ipsum?
  </p>
  <!-- h2 range ends -->
  <h2>Lorem, ipsum dolor.</h2>
  <p>Lorem ipsum dolor sit amet.</p>
  <hr />
  <!-- hr range starts -->
  <p>Lorem ipsum dolor sit.</p>
  <p>Dolor animi nisi ut?</p>
  <p>Sunt consectetur esse quia.</p>
  <!-- hr range ends -->
  <hr />
  <p>Lorem ipsum dolor sit amet consectetur adipisicing elit.</p>
</article>

En utilisant :has() nous pouvons styliser :

• Le premier élément de la plage,
• Le dernier élément de la plage,
• tous les éléments frères et sœurs de la plage.

Ces sélecteurs s'appuient fortement sur le combinateur général ~, qui nous permet à la fois de "regarder vers l'avant" et de styliser plusieurs frères et sœurs à la fois.

Sélectionner le premier élément de la plage

Le CSS qui suit se lit ainsi : "sélectionner le frère ou la sœur adjacent(e) du h2 tant qu'il existe un autre h2 comme frère ou sœur ultérieur(e)", ce qui correspond au paragraphe suivant directement le premier h2 dans notre exemple HTML.

article h2 + :has(~ h2)

Sélectionner le dernier élément de la plage

Le CSS qui suit se lit ainsi : " sélectionner un élément qui suit un h2 tant que son frère ou sa sœur suivant(e) est un h2", ce qui correspond au paragraphe qui précède directement le deuxième h2 dans notre exemple HTML.

article h2 ~ :has(+ h2)

Sélectionner tous les frères et sœurs dans une plage

Le sélecteur suivant est limité en ce sens qu'il ne fonctionne que pour une seule plage au sein d'un parent. En effet, lorsqu'on utilise le combinateur général de frères et sœurs sans indiquer de limite, ces frères et sœurs peuvent se trouver n'importe où après l'élément. On peut donc "sauter" d'autres éléments qui pourraient se trouver entre eux, ce qui a pour effet une plage étendue pour ce sélecteur.

Cela peut être utile si l'on est certain de n'avoir qu'un seul éventail de possibilités au sein d'un parent donné. Ce sélecteur se lit comme suit : "sélectionner tous les éléments frères et sœurs qui suivent un hr et qui ont eux-mêmes un frère et une sœur ultérieurs d'un hr", ce qui correspond aux trois paragraphes entre les éléments hr dans notre exemple HTML.

article hr ~ :has(~ hr)

Nous verrons bientôt comment fixer une limite à notre plage et comment autoriser les groupes à plages multiples dans un seul parent.

voirSelect within an element range with :has() (limited)de smashingmag dansCodePen

Sélection d'une seule plage complète

Dans la série de sélecteurs suivante, nous supposerons que nous avons un élément d'identification supplémentaire à utiliser pour établir le début et la fin de notre plage. Pour les besoins de la démonstration, nous avons une liste où deux éléments de liste ont l'attribut data-range. Cette technique fonctionnerait pour visualiser la fonctionnalité de sélection multiple pour un contrôle personnalisé afin d'afficher la plage des éléments dans la sélection.

<ul>
  <li>Lorem</li>
  <li data-range>Veritatis</li>
  <li>Eos</li>
  <li>Debitis</li>
  <li>Autem</li>
  <li data-range>Atque</li>
  <li>Eius</li>
  <li>Lorem</li>
  <li>Nostrum</li>
</ul>

Nous avons utilisé un attribut data pour signifier le début et la fin, cependant nous supposons qu'aucune valeur d'attribut n'a été fournie. Gardons cela à l'esprit lorsque nous examinerons la construction des sélecteurs d'éléments de début et de fin.

Pour sélectionner à la fois le début et la fin de la plage, nous pouvons simplement utiliser le sélecteur d'attribut [data-range].

Ensuite, nous pouvons réutiliser le sélecteur que nous venons de créer dans la section précédente pour sélectionner tous les frères et sœurs dans la plage.

[data-range]~: has(~[data-range]);

Pour styliser l'élément de plage de départ, le CSS qui suit se lit : "sélectionnez l'élément [data-range] qui a un frère ou une soeur [data-range] quelque part après lui" :

[data-range]: has(~[data-range]);

Et enfin, pour sélectionner l'élément final de la plage, le CSS qui suit se lit : "sélectionnez un élément de [data-range] qui suit quelque part un élément de [data-range]".

[data-range] ~ [data-range]

Dans cette démo CodePen, nous avons également réutilisé nos sélecteurs précédemment créés pour identifier le premier et le dernier élément de la plage.

voirSingle range element selectors with :has()CodePen

Sélection de groupes de plages multiples

Maintenant, nous allons poursuivre notre démo et résoudre le problème de la sélection de plages multiples.

Auparavant, notre problème était qu'un h2 ou un hr dans une série de plus de deux ne nous donnait aucun moyen de déterminer les limites de chacune des plages.

La clé pour rendre possible les groupes à plages multiples au sein d'un seul parent est la disponibilité d'indicateurs de début et de fin distincts.

Nous utiliserons à nouveau des attributs de données sur nos éléments de liste, mais cette fois, nous leur donnerons les valeurs réelles de "start" et "end".

<ul>
  <li>Lorem</li>
  <li data-range="start">Veritatis</li>
  <li>Eos</li>
  <li>Debitis</li>
  <li>Autem</li>
  <li data-range="end">Atque</li>
  <li>Eius</li>
  <li>Lorem</li>
  <li>Nostrum</li>
</ul>

Maintenant que nous avons fourni des valeurs d'attributs explicites, nos sélecteurs de début et de fin sont assez basiques :

/* Éléments de début et de fin de plage */ [data-range] /* Élément de
départ d'une plage */ [data-range="start"] /* Élément de fin d'une
plage */ [data-range="end"]

Allons-y et marquons le premier et le dernier élément de la plage. La première modif par rapport aux versions précédentes consiste à inclure les valeurs des attributs de données de début et de fin. Deuxièmement, nous avons ajouté la condition que le style ne soit pas appliqué à nos indicateurs de début/fin avec la condition d'exclusion :not([data-range]).

/* Premier élément à l'intérieur de la plage */ [data-range="start"] +
:has(~ [data-range="end"]):not([data-range]) /* Dernier élément à
l'intérieur de la plage */ [data-range="start"] ~ :has(+
[data-range="end"]):not([data-range])

Enfin, notre sélecteur doit faire correspondre les éléments à l'intérieur de notre plage. Au départ, il est similaire à ce que nous avons créé précédemment pour les sélecteurs "à l'intérieur de la plage". Une fois encore, nous ajoutons la condition selon laquelle il ne doit pas correspondre à un élément qui est lui-même une [data-range].

[data-range="start"] ~ :has(~ [data-range="end"]):not([data-range])

Mais si vous vous souvenez, j'ai mentionné que le sélecteur général de frères et sœurs a la capacité de "sauter", donc pour l'instant, ce sélecteur va styliser les éléments en dehors de la limite de notre plage prévue. L'image montre comment la règle fonctionne sans autres restrictions.

Pour résoudre ce problème, nous devons ajouter une condition ET complexe à l'aide de :not() afin d'exclure les éléments qui ne se trouvent pas entre [data-range="end"] et [data-range="start"], dans cet ordre.

Seule, cette partie du sélecteur se lit comme suit : "ne pas sélectionner les éléments qui suivent [data-range="end"] et qui ont également un frère ou une soeur plus tardif(ve) de [data-range="start"]".

/* Note : ceci doit être ajouté au sélecteur précédent, et non utilisé seul */
:not([data-range="end"] ~ :has(~ [data-range="start"]))

Au total, cela donne un sélecteur certes long, mais très puissant, qui n'était pas possible avant :has() sans utiliser JavaScript, en raison de l'absence des capacités de "regarder devant" et "regarder derrière" dans CSS.

/* Sélectionner tout ce qui est compris dans une plage */
[data-range="start"] ~ :has(~ [data-range="end"]):not([data-range]):not([data-range="end"] ~ :has(~ [data-range="start"]))

N'oubliez pas que, tout comme les autres sélecteurs, vous pouvez utiliser :has() lorsque vous construisez un sélecteur dans JavaScript. La possibilité de sélectionner des frères et sœurs précédents, des ancêtres et les autres fonctionnalités que nous avons apprises rendront également vos sélecteurs JS plus performants !

voirMulti-range element selectors with :has()de smashingmag dansCodePen

Sélection linéaire d'une plage basée sur l'état

Rassemblons certaines des qualités des sélecteurs et combinateurs :has() que nous avons appris pour créer un composant de classement par étoiles.

L'"étoile" sous-jacente sera une entrée radio, qui nous donnera accès à un état :checked pour nous aider à développer les sélecteurs.

<div class="star-rating">
  <fieldset>
    <legend>Notez cette démo</legend>
    <div class="stars">
      <label class="star">
        <input type="radio" name="rating" value="1" />
        <span>1</span>
      </label>
      <!-- ...4 étoiles de plus -->
    </div>
  </fieldset>
</div>

Comme le montre l'aperçu vidéo qui suit, lorsqu'un utilisateur survole les étoiles soulignées, la plage allant du début (le plus à gauche) à l'étoile survolée doit se remplir de couleur. Lors de la sélection, lorsque le outon radio des étoiles est coché, la taille de l'étoile et du numéro augmente et la couleur de remplissage est conservée. Si l'utilisateur survole des étoiles après l'étoile cochée, la plage doit remplir les étoiles jusqu'au survol. Si l'utilisateur survole les étoiles avant l'étoile cochée, la plage ne doit remplir que jusqu'à l'étoile survolée, et les étoiles situées entre le survol et l'étoile précédemment cochée doivent avoir leur couleur de remplissage éclaircie.

Star-rating preview from Smashing Magazine on Vimeo.

Cela fait beaucoup de plages à gérer, mais avec :has(), nous pouvons les décomposer en sélecteurs segmentés très rapidement !

La série de sélecteurs suivante s'applique à tous les états où nous voulons qu'une étoile ou une plage d'étoiles ait un background bleu jusqu'à l'étoile :checked. La règle met à jour un ensemble de propriétés qui affecteront la forme de l'étoile, créée par une combinaison des pseudo-éléments ::before et ::after sur le label .star.

Au total, cette règle sélectionne la plage d'étoiles entre la première étoile et l'étoile survolée, ou la première étoile et l'étoile avec un bouton radio coché.

.star:hover,
/* Frères et sœurs précédents de l'étoile survolée */
.star:has(~ .star:hover),
/* L'étoile a une radio cochée */
.star:has(:checked),
/* Frères et soeurs précédents d'une étoile cochée */
.star:has(~ .star :checked) {
  --star-rating-bg: dodgerblue;
}

Ensuite, nous voulons éclaircir la couleur de remplissage des étoiles situées entre l'étoile survolée et une étoile cochée ultérieure, et des étoiles cochées qui suivent l'étoile survolée.

/* Frères et sœurs entre une étoile survolée et une étoile cochée */
.star:hover ~ .star:has(~ .star :checked),
/* Étoile cochée suivant une étoile survolée */
.star:hover ~ .star:has(:checked) {
  --star-rating-bg: lightblue;
}

Concernant les sélecteurs d'état pour notre composant de classement par étoiles, c'est tout ce qu'il y a à faire !

La démo CodePen qui suit présente quelques astuces supplémentaires sur la façon dont le composant est créé à l'aide de la grille CSS, des propriétés personnalisées et du clip-path. Pour l'accessibilité, elle garantit également que la couleur n'est pas le seul indicateur en mettant à l'échelle l'étoile cochée. Et il gère les thèmes à fort contraste (alias "couleurs forcées") en fournissant des valeurs de la palette de couleurs du système pour garantir la visibilité du remplissage de l'étoile :checked. En outre, les transitions sont raccourcies lorsqu'un utilisateur préfère un mouvement réduit.

voirStar Rating Component with :has()de smashingmag dansCodePen

Groupes de sélection multi-plages avec état

Alors que le composant de notation par étoiles présentait un changement de style dynamique basé sur l'état, la disponibilité d'éléments avec état facilite également l'utilisation de :has() pour créer des limites visuelles.

Nos précédents sélecteurs multi-plages s'appuyaient sur l'ajout manuel de "crochets" dans le balisage pour styliser correctement les gammes sans s'infiltrer dans les zones intermédiaires. Mais si nous avons un ensemble de champs contenant des cases à cocher, nous pouvons à nouveau utiliser l'état :checked pour identifier clairement les limites autour des éléments cochés et non cochés.

Dans cette vidéo d'aperçu, lorsque les cases à cocher sont sélectionnées, elles reçoivent une bordure et un fond vert pour créer la frontière visuelle. Grâce à :has(), cette limite s'agrandit pour paraître envelopper les groupes d'éléments cochés, de sorte que le cadre visuel semble entourer l'ensemble du groupe. Le premier élément (ou un singleton) reçoit des coins supérieurs arrondis, et le dernier élément (ou un singleton) reçoit des coins inférieurs arrondis ainsi qu'une ombre légère.

Nous devons créer des règles pour gérer l'apparence du haut, du milieu et du bas en fonction de l'emplacement de l'élément dans le jeu. Les éléments uniques doivent recevoir les trois styles.

Notre HTML est configuré pour envelopper chaque entrée de case à cocher avec son étiquette, donc tous nos sélecteurs commenceront par correspondre à label:has(:checked) pour voir si l'étiquette contient une entrée cochée.

Pour déterminer le premier ou l'unique élément de l'ensemble, nous devons ajouter la condition qu'il ne suive pas un élément précédent avec une entrée cochée. Cette règle donnera un style à l'apparence supérieure.

/* Premier élément coché dans une plage
 OU haut d'un élément unique coché */
label:has(:checked):not(label:has(:checked) + label)

Pour déterminer le dernier ou l'unique élément de l'ensemble, nous retournons la condition précédente pour vérifier qu'elle n'est pas suivie d'une entrée cochée. Cette règle donnera un style à l'apparence du bas.

/* Dernier élément coché dans une plage
 OU le bas d'un seul élément coché */
label:has(:checked):not(label:has(+ label :checked))

Pour l'apparence du milieu, nous allons créer une règle qui capture réellement le groupe du début à la fin puisque tous les éléments de la règle doivent recevoir une couleur de fond et des bordures latérales.

Nous pourrions simplement utiliser label:has(:checked) pour ce sélecteur étant donné le contexte. Cependant, nous apprenons à sélectionner et à styliser des plages, donc pour compléter notre exercice, nous allons écrire les sélecteurs étendus.

La logique représentée dans le premier sélecteur est la suivante : "sélectionner les étiquettes avec des entrées cochées qui sont suivies par des étiquettes sœurs contenant des entrées cochées", ce qui capture tous les éléments de la plage sauf le dernier. Pour cela, nous répétons le sélecteur que nous venons de créer pour styliser le dernier élément coché de la plage.

/* Plage d'éléments cochés */
label:has(:checked):has(~ label :checked),
label:has(:checked):not(label:has(+ label :checked))

Cette démo CodePen présente également accent-color pour modifier la couleur de l'entrée cochée et utilise des propriétés personnalisées pour gérer le rayon de la bordure. Elle utilise également des propriétés logiques.

voirStateful multi-range selection groups with :has()de smashingmag dansCodePen

Quelques ressources complémentaires pour écrire des sélecteurs :has()

Vous pouvez explorer toutes les démos dans ma collection CodePen.

D'autres personnes on expérimenté ce qu'on peut faire avec :has(), n'hésitez pas à consulter ces ressources pour vous inspirer. Comme pour toutes les nouvelles fonctionnalités, les possibilités sont nombreuses, et nous en bénéficions tous lorsque nous partageons ce ue nous avons découvert ou appris !

• Bramus Van Damme explore quelques sélecteurs complexes avec :has():
  • Quantity Queries for “islands of elements” with the same class, thanks to CSS :has()
  • A :nth-child(An+B [of S]?) polyfill thanks to CSS :has() and :not()
  • Style a parent element based on its number of children using CSS :has()
• Jhey Tompkins passe en revue des cas pratiques et/ou amusants dans “:has(): The Family Selector”
• Jen Simmons explore les relations de :has() avec les combinateurs et propose quelques démos dans “Utiliser :has() comme sélecteur de parent et bien plus”
• Adrian Bece envisage encore d'autres possibilités dans “Meet :has, A Native CSS Parent Selector (And More)”
• Estelle Weyl démystifie plus encore le comportement du sélecteur “CSS :has()”
• Manuel Matuzović clarifie la différence importante entre “:has(:not()) vs. :not(:has())”

❦

NdT : un exemple intéressant d'utilisation de :has() cité dans la formidable newsletter Bytes :

Si nous voulions mettre en place un effet de style ESPN où l'on assombrit tous les éléments de liste qui ne sont pas survolés, comment pourrions-nous le faire uniquement à l'aide de CSS ?

<ul>
  <li>NBA</li>
  <li>NFL</li>
  <li>NCAAF</li>
  <li>MLB</li>
  <li>NCAAM</li>
  <li>NHL</li>
</ul>

Grâce au nouveau sélecteur :has en CSS, nous pouvons utiliser le sélecteur général sibling (~) et un pseudo-sélecteur :hover pour cibler les éléments avant et après en seulement 3 lignes de css.

ul {
  display: flex;
  gap: 8px;
}
li {
  display: block;
  cursor: pointer;
  transition: opacity 0.3s ease-in-out;
}
li:has(~ li:hover),
li:hover ~ li {
  opacity: 0.5;
}

Vous pouvez le voir en action ici.

La propriété transform nous permet de manipuler visuellement un élément en l'inclinant, le faisant pivoter, le translatant ou le mettant à l'échelle :

.element {
  width: 20px;
  height: 20px;
  transform: scale(20);
}

Même avec une hauteur et une largeur déclarées, cet élément sera maintenant mis à l'échelle à vingt fois sa taille d'origine :

voirTransform explanationde css-tricks dansCodePen

En donnant deux valeurs à cette fonction, nous l'étirons horizontalement de la première valeur (2) et verticalement de la seconde (0.5). Dans l'exemple suivant, l'élément sera désormais deux fois plus large et deux fois moins haut que l'élément d'origine :

.element {
  transform: scale(2, 0.5);
}

Nous pouvons être plus précis, en n'utilisant pas la fonction de raccourci :

transform: scaleX(2);
transform: scaleY(0.5);

Mais scale() n'est qu'une des nombreuses fonctions de transformation disponibles.

Valeurs

scale() : Affecte la taille de l'élément. Cela s'applique également à la taille de la police, au padding, à la hauteur et à la largeur d'un élément. Il s'agit également d'une fonction raccourcie pour les fonctions scaleX et scaleY.

skewX() et skewY() : Incline un élément vers la gauche ou la droite, comme pour transformer un rectangle en parallélogramme. skew() est un raccourci qui combine skewX() et skewY en acceptant les deux valeurs.

translate() : Déplace un élément latéralement ou de haut en bas.

rotate() : Fait pivoter l'élément dans le sens des aiguilles d'une montre à partir de sa position actuelle.

matrix() : Une fonction qui n'est probablement pas destinée à être écrite à la main, mais qui combine toutes les transformations en une seule.

perspective() : N'affecte pas l'élément lui-même, mais affecte les transformées des éléments descendants en 3D, leur permettant d'avoir tous une perspective de profondeur cohérente.

• Skew
• Rotate
• Translate
• Valeurs multiples
• Matrix
• 3D transform

Skew

/* Skew points along the x-axis */
.element {
  transform: skewX(25deg);
}
/* Skew point along the y-axis */
.element {
  transform: skewY(25deg);
}
/* Skew points along the x- and y-axis */
.element {
  transform: skew(25deg, 25deg);
}

Les fonctions de transformation skewX et skewY inclinent un élément dans un sens ou dans l'autre. N'oubliez pas : il n'existe pas de propriété raccourcie pour incliner un élément, vous devrez donc utiliser les deux fonctions. Dans l'exemple ci-dessous, nous pouvons incliner un carré de 100px x 100px vers la gauche et la droite avec skewX :

voirTransform explanationde css-tricks dansCodePen

Dans cet exemple, nous inclinons un élément verticalement avec avec skewY :

voirTransform explanationde css-tricks dansCodePen

Utilisons maintenant skew() pour combiner les deux :

voirTransform explanationde css-tricks dansCodePen

Rotate

.element {
  transform: rotate(25deg);
}

Ce CSS fait tourner un élément dans le sens des aiguilles d'une montre par rapport à sa position d'origine, tandis qu'une valeur négative le ferait tourner dans le sens inverse. Voici un exemple animé simple où un carré tourne en continu de 360 degrés toutes les trois secondes :

voirTransform explanationde css-tricks dansCodePen

Nous pouvons utiliser les fonctions rotateX, rotateY et rotateZ, comme suit :

voirTransform explanationde css-tricks dansCodePen

Translate

.element {
  transform: translate(20px, 10px);
}

Cette fonction de transformation déplace un élément latéralement, ou de haut en bas. Pourquoi ne pas utiliser simplement haut/gauche/bas/droite ? C'est parfois un peu confus. Personnellement, je considère ces fonctions comme des fonctions de mise en page/positionnement (elles sont mieux supportées par les navigateurs de toute façon) et cette fonction comme un moyen de déplacer ces éléments dans le cadre d'une transition ou d'une animation.

Ces valeurs pourraient être n'importe quelle valeur de longueur, comme 10px ou 2.4em. Une valeur déplacera l'élément vers la droite (les valeurs négatives vers la gauche). Si une deuxième valeur est fournie, cette deuxième valeur le déplacera vers le bas (valeurs négatives vers le haut). Vous pouvez aussi être plus spécifique :

transform: translateX(value);
transform: translateY(value);

Il est important de noter qu'un élément utilisant la fonction transform ne fera pas circuler les autres éléments autour de lui. En utilisant la fonction de transformation ci-dessous et en faisant sortir le carré vert de sa position initiale, nous remarquons que le texte qui l'entoure reste fixe en place, comme si le carré était un élément block :

voirTransform explanationde css-tricks dansCodePen

Il convient également de noter que translate sera accéléré par le matériel si vous souhaitez animer cette propriété, contrairement à position: absolute.

Valeurs multiples

.element {
  width: 20px;
  height: 20px;
  transform: scale(20) skew(-20deg);
}

Il est bon de noter qu'il y a un ordre dans lequel ces transformations seront effectuées, dans l'exemple ci-dessus skew sera effectué en premier et ensuite l'élément sera mis à l'échelle.

Matrix

La fonction de transformation matricielle peut être utilisée pour combiner toutes les transformations en une seule. C'est un peu comme un raccourci de transformation, sauf que je ne crois pas qu'il soit vraiment destiné à être écrit à la main. Il existe des outils comme the Matrix Resolutions, qui peuvent convertir un groupe de transformations en une seule déclaration matricielle. Peut-être que dans certaines situations, cela peut réduire la taille du fichier, bien que des micro-optimisations peu amicales pour les auteurs comme celle-ci ne valent probablement pas d'y passer trop de temps.

Pour les curieux, ceci :

rotate(45deg) translate(24px, 25px)

...peut aussi être représenté comme :

matrix(0.7071067811865475, 0.7071067811865476, -0.7071067811865476, 0.7071067811865475, -0.7071067811865497, 34.648232278140824)

3D Transform

La plupart des propriétés que nous avons passées en revue ont des versions 3D.

translate3d(x, y, z)
translateZ(z)

La troisième valeur de translate3d ou la valeur de translateZ rapprochent l'élément de l'observateur, les valeurs négatives l'en éloignent.

scale3d(sx, sy, sz)
scaleZ(sz)

La troisième valeur dans scale3d ou la valeur dans scaleZ affectent la mise à l'échelle le long de l'axe z (par exemple, la ligne imaginaire sortant directement de l'écran).

rotateX(value)
rotateY(value)
rotate3d(x, y, z)

rotateX et rotateY feront tourner un élément dans l'espace 3D autour de ces axes. rotate3d nous permet de spécifier un point dans l'espace 3D autour duquel faire tourner l'élément.

matrix3d(…)

Un moyen programmatique de décrire une transformation 3D dans une grille 4×4. Personne n'en écrira jamais une à la main, jamais.

perspective(value)

Cette valeur n'affecte pas l'élément lui-même, mais elle affecte les transformées 3D des éléments descendants, leur permettant d'avoir tous une perspective de profondeur cohérente.

Plus d'information

• La doc MDN sur transform et son utilisation.
• La documentation de David DeSandro sur 3D transforms
• Surfin’ Safari: 3D transforms
• La spec W3C sur CSS3 transforms
• Intro à CSS 3D transforms par David DeSandro
• Astuces pour utiliser CSS translateZ() et perspective() (DigitalOcean)

Introduction

Les éléments HTML peuvent être dotés d'attributs qui servent à tout, depuis l'ajout d'informations sur l'accessibilité jusqu'au contrôle stylistique.

<!-- Nous pouvons utiliser la "class" pour le style en CSS, et nous avons également fait de cet élément une région de repère -->
<div class="names" role="region" aria-label="Names"></div>

Ce qui est déconseillé, c'est d'inventer vos propres attributs, ou de réaffecter des attributs existants pour une fonctionnalité sans rapport.

<!-- `highlight` n'est pas un attribut HTML -->
<div highlight="true"></div>
<!-- `large` n'est pas une valeur valide de `width` -->
<div width="large"></div>

C'est pas bien, et pour des tas de raisons. Votre HTML devient invalide, ce qui peut ne pas avoir de conséquences négatives réelles, mais vous prive de ce sentiment rassurant et flou d'avoir un HTML valide. La raison la plus convaincante est que le HTML est un langage vivant et ce n'est pas parce que des attributs et des valeurs ne font rien aujourd'hui qu'ils ne feront rien demain.

Bonne nouvelle cependant : vous pouvez créer vos propres attributs. Il vous suffit de les préfixer avec data-* et ensuite vous êtes libre de faire ce qui vous plaît !

Syntaxe

Il est très pratique de pouvoir créer nos propres attributs HTML et d'y placer nos propres informations. Et c'est possible ! c'est même exactement ce que sont les data attributes (attributs de données). Ils sont comme ceci :

<!-- Ils n'ont pas besoin de valeur -->
<div data-foo></div>
<!-- ...mais ils peuvent avoir une valeur -->
<div data-size="large"></div>
<!-- Vous êtes en HTML ici, donc attention à l'échappement du code si vous devez faire quelque chose comme mettre plus de HTML à l'intérieur -->
<li data-prefix="Attention au HTML ici."></li>
<li>
  <!-- Vous pouvez continuer à mettre des tirets si vous voulez -->
  <aside data-some-long-attribute-name><aside></aside></aside>
</li>

Les data attributes sont souvent appelés attributs data-*, car ils sont toujours formatés de cette façon. Le mot data, puis un tiret -, puis un autre texte que vous pouvez inventer.

Pouvez-vous utiliser l'attribut data seul ?

<div data=""></div>

Cela ne va probablement pas faire de mal, mais vous n'obtiendrez pas l'API JavaScript que nous verrons plus tard dans ce guide. Vous vous créez essentiellement un attribut pour vous-même, ce qui, comme je l'ai mentionné dans l'introduction, est déconseillé.

Ce qu'il ne faut pas faire avec les data attributes

Stockez du contenu qui doit être accessible. Si le contenu doit être vu ou lu sur une page, ne le mettez pas seulement dans des data attributes, mais assurez-vous que ce contenu se trouve quelque part dans le contenu HTML.

<!-- Ce n'est pas du contenu accessible -->
<div data-name="Chris Coyier"></div>
<!-- Si vous avez besoin d'un accès programmatique à ce contenu mais qu'il ne doit pas être vu, il existe d'autres moyens... -->
<div>
  <span class="visually-hidden">Chris Coyier</span>
</div>

Voici plus d'informations sur le masquage des choses.

Stylisation avec des data attributes

CSS peut sélectionner des éléments HTML sur la base d'attributs et de leurs valeurs.

/* Sélectionner tout élément ayant cet attribut de données et cette valeur */
[data-size='large'] {
  padding: 2rem;
  font-size: 125%;
}
/* Vous pouvez l'étendre à un élément, une classe ou n'importe quoi d'autre */
button[data-type='download'] {
}
.card[data-pad='extra'] {
}

Cela peut être convaincant. Les principaux hooks de style en HTML/CSS, ce sont les classes, et bien que les classes soient excellentes (elles ont une spécificité moyenne et de belles méthodes JavaScript via classList), un élément en est doté ou non, c'est l'un ou l'autre, (essentiellement activé ou désactivé). Avec les attributs data-*, vous obtenez cette capacité d'activation/désactivation, et la possibilité de sélectionner en fonction de la valeur qu'il possède au même niveau de spécificité.

/* Sélectionne si l'attribut est présent du tout */
[data-size] {
}
/* Sélectionne si l'attribut a une valeur particulière */
[data-state='open'],
[aria-expanded='true'] {
}
/* Sélecteur "Commence par", ce qui signifie que cela correspond à "3" ou à tout ce qui commence par 3, comme "3.14" */
[data-version^='3'] {
}
/* "Contient" signifie que la valeur contient la chaîne de caractères n'importe où à l'intérieur */
[data-company*='google'] {
}

La spécificité des sélecteurs d'attributs

C'est exactement la même chose qu'une classe. Nous pensons souvent à la spécificité comme à une valeur en quatre parties :

style en ligne, IDs, classes/attributs, balises.

Ainsi, un sélecteur d'attribut seul est 0, 0, 1, 0. Un sélecteur comme celui-ci :

div.card[data-foo='bar'] {
}

... serait 0, 0, 2, 1 — le 2 est dû au fait qu'il y a une classe (.card) et un attribut ([data-foo="bar"]), et le 1 est dû au fait qu'il y a une balise (div).

Les sélecteurs d'attributs ont moins de spécificité qu'un ID, plus qu'un élément/balise, et la même chose qu'une classe.

Valeurs d'attributs insensibles à la casse

Au cas où vous auriez besoin de corriger d'éventuelles incohérences de capitalisation dans vos data attributes, le sélecteur d'attribut dispose d'une variante insensible à la casse pour cela.

<!-- Correspondra à
<div data-state="open"></div>
<div data-state="Open"></div>
<div data-state="OPEN"></div>
<div data-state="oPeN"></div>
-->
[data-state="open" i] { }

C'est le petit i à l'intérieur du sélecteur entre crochets.

Utilisation visuelle des data attributes

CSS vous permet d'extraire la valeur de l'attribut de données et de l'afficher si nécessaire.

/* <div data-emoji="✅"> */
[data-emoji]::before {
  content: attr(data-emoji); /* Retourne '✅' */
  margin-right: 5px;
}

Exemple de cas d'utilisation du style

Vous pourriez utiliser des data attributes pour spécifier le nombre de colonnes que vous souhaitez pour un conteneur de grille.

<div data-columns="2"></div>
<div data-columns="3"></div>
<div data-columns="4"></div>

voirData Attribute Based Columnsde chriscoyier dansCodePen

Accéder aux data attributes en JavaScript

Comme tout autre attribut, vous pouvez accéder à la valeur avec la méthode générique getAttribute.

let value = el.getAttribute('data-state')
// Vous pouvez également définir la valeur.
// Returns data-state="collapsed"
el.setAttribute('data-state', 'collapsed')

Mais les data attributes ont également leur propre API spéciale. Admettons que vous ayez un élément avec plusieurs data attributes (ce qui est tout à fait ok) :

<span
  data-info="123"
  data-index="2"
  data-prefix="Dr. "
  data-emoji-icon="?️♀️"
></span>

Si vous avez une référence à cet élément, vous pouvez définir (set) et obtenir (get) les attributs comme suit :

// GET
span.dataset.info // 123
span.dataset.index // 2
// SET
span.dataset.prefix = 'M. '
span.dataset.emojiIcon = '?'

Notez l'utilisation du camelCase dans la dernière ligne. Elle convertit automatiquement les attributs de style kebab en HTML, comme data-this-little-piggy, en style camelCase en JavaScript, comme dataThisLittlePiggy.

Cette API n'est sans doute pas aussi agréable que classList avec ses méthodes claires d'ajout, de suppression, de basculement (toggle) et de remplacement, mais c'est mieux que rien.

Vous avez également accès aux ensembles de données en ligne :

<img src="spaceship.png"
  data-ship-id="324" data-shields="72%"
  onclick="pewpew(this.dataset.shipId)">
</img>

Données JSON à l'intérieur des data attributes

<ul>
  <li
    data-person='
    {
      "nom" : "Chris Coyier",
      "job" : "Personne Web"
    }
  '
  ></li>
</ul>

Hé, pourquoi pas ? Ce n'est qu'une chaîne de caractères et il est possible de la formater en JSON valide (attention aux guillemets et autres). Vous pouvez extraire ces données et les parser selon vos besoins.

const el = document.querySelector('li')
let json = el.dataset.person
let data = JSON.parse(json)
console.log(data.name) // Chris Coyier
console.log(data.job) // Personne Web

Cas d'utilisation de JavaScript

Le concept est que vous pouvez utiliser les data attributes pour mettre dans le HTML des informations auxquelles JavaScript peut avoir besoin d'accéder pour faire certaines choses.

Un cas courant serait lié à la fonctionnalité de la base de données. Disons que vous avez un bouton "J'aime" :

<button data-id="435432343">♡</button>

Ce bouton pourrait être doté d'un click handler qui exécute une requête Ajax vers le serveur pour incrémenter le nombre de j'aime dans une base de données à chaque clic. Il sait quel enregistrement mettre à jour car il l'obtient du data attribute.

Spécifications

• Sélecteurs niveau 4 (projet)
• Sélecteurs niveau 3 (recommandé)
• Sélecteurs de niveau 2, révision 1 (définition initiale)

Le texte qui suit est paru dans le site de Kitty Giraudel, qui écrit : "voici un billet invité de Jesús Ricarte, développeur frontend et traducteur bénévole pour A List Apart en espagnol. Je suis très heureux qu'il nous parle aujourd'hui de la hauteur des lignes et de l'utilisation des mathématiques en CSS !"

❦

Nous pouvons appliquer n'importe quelle unité CSS à la hauteur de ligne (line-height), cependant une valeur sans unité de 1.5 est la façon la plus recommandée de gérer cette hauteur. Pour commencer, voici une image explicative sur la façon dont la hauteur de ligne est appliquée par le navigateur :

Comme vous pouvez le constater, chaque hauteur de ligne est répartie dans différentes zones :

• Une "zone de contenu", dont la hauteur serait égale à 1.
• Une "zone d'espace", qui serait l'espace restant, réparti de manière égale en haut et en bas de la ligne. (NdT: le leading ou espacement de ligne ou interlignage.

Nous pourrions donc l'exprimer comme suit : lineHeight = leading / 2 + content + leading / 2

ou :

line-height: calc(0.25 + 1 + 0.25);

Cette approche présente toutefois un inconvénient en termes de maintenance : comme vous pouvez le constater dans la démo suivante, elle fixe une hauteur de ligne trop importante dans les grandes tailles de police. Afin d'établir une lisibilité optimale, nous devons l'ajuster manuellement à chaque incrément de font-size, jusqu'à 1.1 pour les très grandes tailles de police.

voircalc line-height: demo 1de super-simple.net dansCodePen

À la recherche d'une formule

Pour y voir plus clair, jetons un coup d'œil à nos chiffres de démonstration, sur un tableau de comparaison (les valeurs de hauteur de ligne calculées sont en pixels pour une meilleure compréhension) :

Pour obtenir une hauteur de ligne optimale, nous devrons être aussi proches que possible de la valeur 1.5 (15px), sur les petites tailles de police, mais plus proches de 1.1 (55px) sur les grandes.

Attendez... 11px est déjà assez proche de 15px. Nous sommes à quelques pixels près.

Donc, au lieu de commencer sur une valeur de 1.5, pourquoi ne pas inverser les choses ? Nous pourrions commencer à partir de 1.1, en ajoutant juste les quelques pixels dont nous avons besoin, ce qui ne fera presque aucune différence visuelle dans les grandes tailles de police, seulement dans les petites.

Quelque chose comme :

line-height: calc(2px + 1.1 + 2px);

Révision de notre tableau de comparaison des hauteurs de ligne calculées :

Voilà qui est mieux ! Nous avons réussi dans les petites tailles de police et nous en sommes assez proches dans les grandes.

Malheureusement, line-height : calc(2px + 1.1 + 2px) n'est pas un CSS valide, puisque les valeurs avec unité et sans unité ne peuvent pas être mélangées. Pourrions-nous utiliser n'importe quelle unité relative qui est calculée à environ 1.1 ?

Genre : l'unité ex est calculée à la hauteur d'x de la police actuelle (la hauteur de la lettre minuscule "x"), donc nous trouvons simplement la correspondance parfaite pour notre formule.

En fait, toute unité relative (em, rem...) peut être utilisée, mais puisque nous calculons la hauteur de ligne, il est logique d'utiliser une unité de hauteur.

Comme chaque police de caractères a sa propre valeur ex, nous devons encore affiner nos valeurs px & ex. Quoi qu'il en soit, considérez ceci comme un bon point de départ :

line-height: calc(2px + 2ex + 2px);

Comme vous pouvez le voir dans la démo suivante, il définit une très belle hauteur de ligne, dans un large éventail de caractères différents :

voircalc line-height: demo 2de super-simple.net dansCodePen

C'est du CSS valide. De plus, l'unité ex a une très bonne compatibilité navigateur. Hourra !

Éléments descendants

Si vous appliquez la formule sur un élément parent, et que la taille de la police est modifiée sur un élément descendant, la hauteur de ligne ne sera pas affectée sur le descendant, puisqu'elle a été calculée sur la base de la taille de la police du parent :

.parent {
  font-size: 20px;
  line-height: calc(2px + 2ex + 2px);
  /* calculé: 2px + (2 * 20px) + 2px = 44px */
}
.parent .descendant {
  font-size: 40px;
  /* désiré:  2px + (2 * 40px) + 2px = 84px */
  /* calculé: 2px + (2 * 20px) + 2px = 44px (comme .parent) */
}

Cela peut être résolu en appliquant la formule à tous les descendants, avec le sélecteur universel :

.parent * {
  line-height: calc(2px + 2ex + 2px);
}

De la typographie responsive

Notre formule est également utile pour la typographie responsive. L'utilisation d'unités relatives au viewport (vw, vh, vmin, vmax) entraîne un manque de contrôle fin, de sorte que nous ne pouvons pas modifier la hauteur de ligne à chaque changement de taille de police.

Ce problème a également été abordé par la technique des verrous CSS, qui utilise une arithmétique relativement complexe pour établir une hauteur de ligne minimale et maximale. NdT : Depuis la publication, en 2016, de l'article de Florens Verschelde en lien ci-dessus, CSS a gagné une nouvelle capacité qui remplace une grande partie de l'astuce de cet article : la fonction clamp().La Cascade utilise :

body {
  line-height: calc(1em + 0.5rem);
}

CSS nous permet de créer toutes sortes de formes. Les carrés et les rectangles sont faciles, car ce sont les formes naturelles du Web. Ajoutez une largeur et une hauteur et vous obtenez la taille exacte du rectangle dont vous avez besoin. Ajoutez un rayon de bordure et vous pouvez arrondir cette forme, et avec le rayon approprié, vous pouvez transformer ces rectangles en cercles et en ovales.

Nous disposons également des pseudo-éléments ::before et ::after en CSS, qui nous offrent le potentiel de deux formes supplémentaires que nous pouvons ajouter à l'élément original. En faisant preuve d'ingéniosité avec le positionnement, la transformation et bien d'autres autres astuces, nous pouvons créer de nombreuses formes en CSS avec un seul élément HTML.

De nos jours, notre meilleur atout pour dessiner des formes est soit le SVG, soit l'utilisation d'un clip-path en CSS, qui fonctionne un peu comme SVG (et peut faire référence au SVG). Par exemple, regardez ces jeux d'icônes SVG, cet éditeur de clip-path, et cette introduction au clipping CSS. Cet article a été écrit à l'origine avant que l'une ou l'autre de ces technologies ne s'impose vraiment !

Carré

Rectangle

Cercle

Ovale

Triangle vers le haut

Triangle vers le bas

Triangle vers la gauche

Triangle vers la droite

Triangle rectangle en bas à droite

Trapezoïde

Parallèlogramme

Étoile (6 points)

Carreau resserré via Joseph Silber

Bulle

Écran télé

Drapeau via Zoe Rooney

Croix via Kaya Basharan

Enveloppe via Josh Rodgers

Pointeur (via Amsakanna / alt)

Cadenas

Coins (via Zberno)

NdT: et pour terminer, vous pouvez voir aussi ces diapos de Sara Soueidan qui recommande SVG plutôt que CSS. Pour clip-path, vous pouvez consulter ici Comprendre clip-path. Pour SVG, les articles ne manquent pas dans la Cascade, en particulier la série des "Bases de SVG".

Ajouter une image avec HTML c'est assez facile, n'est-ce pas ? c'est juste une simple balise, après tout...

<img src="path/to/image.jpg" />

Mais lorsque nous commencons à prendre en considération la performance, les tailles d'écran, l'accessibilité, la densité de pixels ou les préférences de l'utilisateur, on peut finir par se demander si HTML est suffisant à lui seul pour cette tâche... Et la réponse est oui ! Le HTML a de nombreuses options et il est suffisamment puissant pour gérer cette tâche. Cet article traitera de ce que nous devons considérer au moment d'ajouter une image à un site avec HTML.

Considérations de base

Attribut alt

Commençons par un élément très important : votre image a besoin d'un texte alternatif. Ça permettra aux utilisateurs de lecteurs d'écran d'identifier le contenu de l'image, mais ça les aidera également lorsque l'image ne se charge pas (peut-être parce que l'image n'est pas disponible, ou peut-être parce que l'utilisateur a un réseau lent). Sinon, ils ne sauront pas ce qu'est l'image. Cela peut être fait avec l'attribut alt.

<img
  src="path/to/image.jpg"
  alt="Un chat blanc allongé sur un canapé"
/>

Gardez à l'esprit que parfois, une image est là à des fins purement décoratives, donc la rendre visible pour les lecteurs d'écran pourrait ne pas être idéal, dans ce cas, nous pouvons utiliser un alt vide pour que les lecteurs d'écran ignorent cette image.

<img src="path/to/image.jpg" alt="" />

Que doit contenir le texte alternatif ? En général, il doit contenir une description concise de ce que contient l'image. S'il s'agit d'une image contenant des informations importantes (comme le lieu d'un événement ou une infographie complète), ces informations doivent également figurer dans le texte alternatif. Le W3C a créé un arbre de décision alt pour nous aider à décider des informations à ajouter.

Attributs de largeur et de hauteur

L'une des mesures les plus importantes des performances est le décalage cumulatif de la mise en page (Cumulative Layout Shift, CLS), qui évalue dans quelle mesure le contenu d'un site Web se déplace lorsqu'il est à l'écran. En d'autres termes, un CLS faible signifie que le contenu est assez stable et ne créera aucun problème avec l'interactivité de l'utilisateur. Pour en savoir plus sur ce concept, vous pouvez consulter cet article sur web.dev à propos de CLS.

Le chargement d'images peut créer des problèmes de décalage de mise en page et une façon de les éviter est d'utiliser les attributs width et height pour les images. Ils indiquent au navigateur la taille intrinsèque de l'image et créent le ratio d'aspect de l'image lors du chargement du site Web, ce qui réduit le décalage de mise en page qu'il peut créer. Voici à quoi cela ressemblerait dans une image.

<img
  src="path/to/image.jpg"
  alt="Un chat blanc couché sur un canapé"
  width="1200"
  height="800"
/>

Mais ce n'est pas tout ce que nous pouvons faire pour améliorer les performances de notre site Web avec une balise img !

Chargement paresseux

Nous pouvons avoir beaucoup d'images sur notre site Web, et cela peut affecter son temps de chargement. C'est là qu'intervient le concept de chargement paresseux (lazy loading). Ça signifie que l'image ne commencera à se charger que lorsqu'elle se trouvera dans la partie visible de la fenêtre d'affichage. Il fut un temps où cela se faisait avec JavaScript mais maintenant HTML nous offre un moyen de le faire facilement en utilisant l'attribut loading="lazy".

<img
  src="path/to/image.jpg"
  alt="Un chat blanc couché sur un canapé"
  width="1200"
  height="800"
  loading="lazy"
/>

Lorsque nous utilisons loading="lazy" en tandem avec les attributs height et width, nous nous assurons que le site Web dispose de suffisamment d'espace pour l'image au moment du chargement, et en même temps, nous ne chargons l'image que si l'utilisateur en a besoin, ce qui est excellent pour les performances !

N'oublions pas cependant que si un utilisateur a désactivé JavaScript, loading="lazy" ne fonctionnera pas. Nous devons donc garder à l'esprit d'autres considérations liées aux performances, mais mettons ce sujet en veilleuse pour l'instant.

N'oublions pas non plus que l'utilisation de loading="lazy" dans notre élément Largest Content Painting (nous parlerons de cette métrique plus tard) augmentera en fait notre temps de chargement. Soyons donc prudent et testons toujours cet élément pour savoir si cet attribut donne les résultats escomptés.

figure et figcaption

Parfois, nous devons ajouter des informations supplémentaires qui ne tiendraient pas dans la balise alt, comme les crédits de l'image, ou une note importante à son sujet à laquelle nous préférons que tout le monde ait accès. Nous pouvons utiliser la balise figure pour envelopper l'img, puis ajouter une légende avec la balise figcaption.

<figure>
  <img
    src="path/to/image.jpg"
    alt="Un chat blanc couché sur un canapé"
    width="1200"
    height="800"
    loading="lazy"
  />
  <figcaption>
    Les chats persans sont reconnaissables à leurs gros poils, leur
    visage rond et leur museau court
  </figcaption>
  .
</figure>

figcaption doit être un enfant direct de l'élément figure, sinon, il pourrait ne pas être reconnu par les technologies d'assistance. C'est un point que Manuel souligne dans son article divs are bad!.

Garder ces considérations à l'esprit aide beaucoup lorsque nous créons une image, mais ce n'est que la partie émergée de l'iceberg. Lorsque nous commençons à prendre en considération de multiples variables comme les tailles d'écran, les formats d'image et les préférences des utilisateurs, la balise img commence à manquer de puissance. C'est là qu'une autre balise entre en jeu pour ajouter plus de fonctionnalités !

La balise picture

Cette balise est un conteneur pour de multiples sources d'images. Selon les conditions que nous y ajoutons, le navigateur commencera à choisir le bon fichier en fonction de multiples facteurs comme la taille du viewport, le format de l'image, la densité des pixels ou les préférences de l'utilisateur. Il agit comme un emballage pour les multiples éléments de source que nous utiliserons pour déterminer la meilleure image.

Commençons par vérifier ce que nous pouvons faire avec cet élément.

Prise en charge de différents formats d'image

À côté des formats d'image .png ou .jpg, il existe de nouveaux formats d'image tels que .avif, .webp ou .apng que nous pourrions vouloir utiliser parce qu'ils ne présentent pas de perte de qualité tout en étant beaucoup moins lourds qu'un format plus courant. Cependant, les formats d'image mentionnés précédemment bénéficient d'une prise en charge plus large. Nous pouvons utiliser la balise source pour nous permettre d'utiliser des formats d'image plus optimisés en fonction du support du navigateur. Pour cela, nous pouvons utiliser l'attribut type dans l'élément source pour indiquer le format que nous devons évaluer.

<picture>
  <source srcset="path/to/image.avif" type="image/avif" />
  <source srcset="path/to/image.webp" type="image/webp" />
  <img
    src="path/to/image.jpg"
    alt="Un chat blanc couché sur un canapé"
    width="1200"
    height="800"
    loading="lazy"
  />
</picture>

Dans ce cas, il commencera à vérifier si le navigateur accepte le format .avif, et si ce n'est pas le cas (comme Safari avant la version 16), il vérifiera si le format .webp est supporté. Si ce n'est pas le cas, il affichera celui de l'élément img. Il existe de nombreux formats d'image. Si vous voulez en savoir plus, vous pouvez consulter la documentation de MDN à ce sujet.

Vous vous souvenez que j'ai mentionné que loading="lazy" pourrait ne pas être suffisant pour des raisons de performances ? Ça nous aidera à prendre en compte la compatibilité navigateur pour charger l'image optimale, créant ainsi un système très robuste pour donner à l'utilisateur la meilleure qualité d'image possible et utiliser le moins de bande passante possible. C'est le meilleur des deux mondes, et c'est possible avec seulement du HTML !

Images responsives

Nous pourrions vouloir montrer une image différente ou une partie différente d'une image en fonction de la taille du viewport. L'élément picture peut nous y aider grâce à l'attribut media, où nous pouvons utiliser une requête media pour détecter la taille du viewport et ajouter une image différente si nécessaire.

<picture>
  <source
    srcset="path/to/image-mobile.jpg"
    media="(max-width : 600px)"
  />
  <img
    src="path/to/image.jpg"
    alt="Un chat blanc couché sur un canapé"
    width="1200"
    height="800"
    loading="lazy"
  />
</picture>

Nous pouvons y utiliser n'importe quelle requête média valide. Ainsi, par exemple, orientation : portrait et orientation : landscape sont des options valides lorsque nous souhaitons afficher une image différente selon que la largeur du viewport est supérieure (ou inférieure) à sa largeur. Il existe de nombreuses possibilités que nous pouvons envisager pour donner la meilleure image à l'utilisateur.

Préférences de l'utilisateur

Maintenant, c'est très pratique pour les performances et l'expérience utilisateur, mais c'est également utile pour l'accessibilité : nous pouvons vérifier les préférences de l'utilisateur pour aider les personnes souffrant de certains handicaps.Par exemple, certaines personnes peuvent avoir des problèmes comme des migraines et préférer utiliser le mode sombre, et une image très lumineuse pourrait déclencher une crise de migraine, donc avoir une version de votre image mieux adaptée au mode sombre serait idéal.

Ou peut-être avons-nous un gif, et quelqu'un a désactivé les animations sur son appareil. Nous pourrions vouloir montrer une image statique à la place afin que son expérience ne soit pas affectée. Comment faire ?

Comme je l'ai mentionné, nous pouvons utiliser n'importe quelle requête média valide, ce qui inclut les requêtes média qui vérifient les préférences de l'utilisateur comme prefers-color-scheme ou prefers-reduced-motion. Nous pouvons même les combiner avec des opérateurs logiques pour afficher l'image appropriée. Voyons comment cela fonctionne avec un exemple.

<picture>
  <!-- La préférence pour le mode sombre et les animations sont désactivées -->
  <source
    srcset="path/to/image-dm.jpg"
    media="(prefers-reduced-motion : reduce) and (prefers-color-scheme : dark)"
  />
  <!-- Image statique lorsque les animations sont désactivées -->
  <source
    srcset="path/to/image.jpg"
    media="(prefers-reduced-motion : reduce)"
  />
  <!-- La préférence pour le mode sombre est vérifiée -->
  <source
    srcset="path/to/image-dm.gif"
    media="(prefers-color-scheme : dark)"
  />
  <!-- Aucune de ces préférences n'est active -->
  <img
    src="path/to/image.gif"
    alt="Un chat qui danse"
    width="1200"
    height="800"
    loading="lazy"
  />
</picture>

Il est important de noter ici que l'ordre a de l'importance. Il est préférable d'ajouter d'abord les balises ayant des exigences plus spécifiques en matière de requête média pour être sûr qu'elles ne seront pas écrasées par celles qui apparaîtront plus tard. Gardez également à l'esprit que vous pouvez combiner tout ce que vous avez vu, il y a donc beaucoup de possibilités avec les éléments picture et source.

Cela couvre pratiquement tout ce que vous devez prendre en considération, mais il y a encore quelques points que vous pouvez prendre en compte.

Considérations supplémentaires

Densité des pixels et srcset

L'attribut srcset que nous utilisons dans l'élément picture a une syntaxe légèrement différente si nous souhaitons donner une meilleure image en fonction de la densité de pixels de l'appareil. Pour cela, nous pouvons ajouter une liste d'images séparées par des virgules et après l'URL de l'image, nous mettrons le type de densité de pixels que nous voulons prendre en charge avec cette image. Voyons cela avec un exemple :

<picture>
  <source
    srcset="
      path/to/image-mobile.jpg    1x,
      path/to/image-mobile-2x.jpg 2x,
      path/to-image-mobile-3x.jpg 3x
    "
    media="(max-width : 600px)"
  />
  <img
    src="path/to/image.jpg"
    alt="Un chat blanc couché sur un canapé"
    width="1200"
    height="800"
    srcset="path/to/image-2x.jpg 2x, path/to/image-3x.jpg 3x"
    loading="lazy"
  />
</picture>

Il y a encore quelque chose que je n'ai pas mentionné et c'est le fait que nous pouvons utiliser l'attribut srcset dans l'élément img, et cela fonctionne très bien lorsque nous voulons prendre en charge des images en fonction de la densité de pixels de l'appareil. La prochaine fois que vous voudrez apporter des images de meilleure qualité pour les images en fonction de l'appareil, vous savez maintenant comment faire !

Précharger l'image pour améliorer le LCP

Vous vous souvenez quand j'ai mentionné LCP ? Il existe une autre métrique appelée Largest Content Paint (LCP) qui mesure le temps nécessaire pour charger la plus grande image (ou bloc de texte) à rendre dans le viewport. Généralement, ce LCP est une grande image. Nous pouvons utiliser d'autres formats d'image pour diminuer la taille du LCP, mais que faire si cela ne suffit pas ? Nous avons l'alternative de précharger l'image dans le head, ce qui rendra l'image plus rapide, et par extension, améliorera cette métrique. Voici à quoi cela ressemblerait dans notre balise head.

<head>
  <link rel="preload" href="path/to/image.jpg" as="image" />
</head>

Atention à ne pas abuser de cette technique cependant, car sinon, elle augmentera le temps de chargement de la page. Utilisez-la simplement pour votre ou vos images les plus importantes et testez les performances en conséquence pour vérifier si elle améliore ces métriques.

`décodage="async"``

J'ai déjà mentionné loading="lazy", mais il existe un autre attribut HTML que nous pouvons utiliser pour optimiser le temps de chargement d'un site Web. Alors que loading="lazy" décide du moment où l'image sera chargée (au moment où elle est proche du viewport), nous avons un autre attribut qui définit comment elle sera chargée.

Normalement, tout notre site sera chargé de manière synchrone parce que le navigateur lit le HTML ligne par ligne, donc s'il trouve une grande image, le reste du site ne se téléchargera pas avant que l'image soit chargée. C'est là que decoding="async" entre en jeu pour donner une indication au navigateur d'essayer de télécharger l'image et en même temps de télécharger une autre partie du site.

<img
  alt="Un chat blanc allongé sur un canapé"
  width="1200"
  height="800"
  loading="lazy"
  decoding="async"
/>

L'utilisation des deux, decoding="async" et loading="lazy", dans une image contribuera à réduire considérablement le temps de chargement d'un site Web, et le decoding est un attribut largement pris en charge.

Conclusion

Ajouter une image à un site Web est facile... Mais les choses commencent à se compliquer lorsque nous commençons à prendre en compte les considérations de performance et d'accessibilité. Heureusement pour nous, HTML peut nous donner les outils appropriés pour aborder ces considérations sans aucun problème.

J'ai choisi ce sujet pour ce calendrier de l'Avent pour une bonne raison et c'est parce qu'il m'a fait remarquer à quel point le HTML est puissant, robuste et étonnamment complexe. Voir ce que le HTML a à offrir juste pour amener la bonne image sur votre écran avec un effort relativement faible était fascinant et cela m'a donné envie de creuser plus profondément dans ce que le HTML peut faire.

On me demande régulièrement des recommandations sur les frameworks d'interface utilisateur. Par "framework d'interface utilisateur", j'entends tout package tiers qui se concentre sur la fourniture de composants d'interface utilisateur stylisés. Ça comprend les frameworks CSS comme Bootstrap, et les bibliothèques de composants JS comme Material UI ou Ant Design.

Ma réponse à cette question prend généralement les gens au dépourvu : je ne les utilise pas, et je ne pense pas qu'ils devraient être utilisés. ?

Pour être clair, je n'ai rien contre ces outils, et je pense qu'il en existe des cas d'utilisation valables. Mais j'ai vu trop de développeurs se jeter sur ces outils avec des attentes irréalistes quant aux problèmes qu'ils veulent résoudre ou à la facilité avec laquelle ils vont pouvoir créer des applications.

Dans cet article, je vais expliquer pourquoi vous n'avez probablement pas besoin de ces outils. Je vous ferai également part de quelques-unes de mes stratégies pour créer des applications d'aspect professionnel sans avoir de formation en design.

L'attrait des frameworks

Les raisons d'opter pour un framework d'interface utilisateur sont nombreuses. Voici les trois plus courantes que j'ai constatées :

1. Les développeurs veulent que leur application/site ait une apparence soignée et professionnelle, et ces outils fournissent des composants d'interface utilisateur joliment conçus.
2. Ils veulent être rapidement opérationnels sans passer trop de temps à tout construire de zéro.
3. Ils reconnaissent que de nombreux composants de l'interface utilisateur, tels que les modales, les listes déroulantes et les infobulles, sont très difficiles à réaliser correctement, surtout si l'on tient compte de l'accessibilité, et ils veulent donc être sûrs de bien faire les choses.

Ce sont des souhaits tout à fait raisonnables, et je peux absolument comprendre l'intérêt de trouver une solution à ces problèmes. Mais dans certains cas, je pense qu'il y a un décalage entre les attentes et la réalité. Dans d'autres, je pense qu'il existe de meilleurs outils pour ce travail.

Entrons dans le vif du sujet.

Design professionnel

Cette première raison est peut-être la plus courante. Il y a des tonnes de développeurs qui veulent construire des choses, mais qui n'ont pas de formation en design. Plutôt que de passer des années à apprendre le design, pourquoi ne pas utiliser une bibliothèque qui fournit des composants magnifiquement conçus dès la sortie de la boîte ?

Voici le problème, à mon avis : le design, c'est bien plus que de belles pièces.

Il y a quelque temps, j'ai reçu en cadeau une Nintendo Entertainment System LEGO :

C'était un kit vraiment amusant à construire. Si vous êtes un fan de LEGO, je vous recommande vivement de le découvrir !

Voici le point, cependant : j'ai pu construire ce modèle parce que le kit était accompagné d'un livre de 200 pages qui me disait exactement où placer chaque brique.

Si l'on m'avait donné toutes les pièces sans instructions, mon NES aurait l'air bien pire que ce qu'il est. Il ne suffit pas d'avoir des briques de haute qualité, il faut aussi savoir comment les utiliser.

Une bibliothèque de composants peut vous donner de jolis boutons, des sélecteurs de date et des widgets de pagination, mais c'est toujours à vous de les assembler.

Les blocs d'un système de conception comme Material Design ont été construits par une équipe de design talentueuse. Cette équipe comprend le framwork et possède les compétences nécessaires pour assembler les pièces en de magnifiques interfaces. Nous avons accès aux mêmes pièces, mais cela ne signifie pas que nous obtiendrons automatiquement les mêmes résultats.

Je me souviens avoir entendu un designer dire que seul Google pouvait créer des applications Material Design qui soient belles. L'App Store d'Android est plein d'applications qui utilisent les mêmes composants conçus par des professionnels, mais qui n'ont pas du tout l'air professionnels.

Un bon design comporte tellement d'aspects intangibles - des choses comme l'équilibre, l'espacement et la cohérence. Pour utiliser efficacement une bibliothèque de composants, vous devez vous mettre à la place des designers qui l'ont créée et comprendre comment ils sont censés être déployés.

De plus, aussi complète que soit la bibliothèque, elle ne contiendra jamais toutes les pièces dont vous avez besoin. Chaque application, chaque site Web est unique, et il y aura toujours des exigences particulières. Créer un tout nouveau composant qui se "fond" dans un système de design existant est vraiment très difficile.

Je ne pense pas que ce soit impossible - je suis même sûr qu'il existe des exemples d'applications d'aspect professionnel utilisant des styles tiers. Mais si vous êtes capable de le faire, c'est que vous avez probablement de sacrés talents de designer et que vous n'avez pas besoin de ces outils pour commencer.

Je compatis avec les développeurs qui veulent lancer un projet d'apparence professionnelle sans aucune sorte d'intuition en matière de design... Mais cela ne fonctionne généralement pas de cette façon, d'après ce que j'ai vu.

Gagner du temps

La raison suivante que j'ai entendue est que les frameworks d'interface utilisateur permettent de gagner du temps. Construire toute une bibliothèque de composants à partir de zéro est une entreprise importante qui peut être évitée en s'appuyant sur un framework d'interface utilisateur.

Il y a une part de vrai dans cette affirmation, mais d'après ce que j'ai souvent constaté, l'apprentissage c'est l'histoire du lièvre et de la tortue. Voici mon expérience :

J'ai passé quelques années à enseigner les principes fondamentaux du design Web aux étudiants du bootcamp de l'Université Concordia. Le programme se termine par un projet personnel de deux semaines. Les étudiants décident de ce qu'ils veulent construire, et c'est à eux de le faire. En tant qu'instructeur, je répondais aux questions et je les aidais quand ils étaient bloqués.

Nous avons remarqué une tendance : les étudiants qui choisissent un cadre d'interface utilisateur comme Bootstrap ou Material UI se lancent rapidement et font des progrès rapides les premiers jours. Mais au fil du temps, ils s'enlisent. L'écart entre ce dont ils ont besoin et ce que la bibliothèque de composants fournit apparaît progressivement au grand jour. Et ils finissent par passer beaucoup de temps à essayer de plier les composants à forme voulue.

Je me souviens d'un étudiant qui a passé tout un après-midi à essayer de modifier l'entête d'un framework CSS pour soutenir sa navigation. À la fin, le groupe a décidé de supprimer le composant tiers et ils ont construit eux-mêmes une alternative en 10 minutes.

Écrire vos propres styles me semble un peu comme écrire des tests : c'est un peu plus lent au début, mais cet effort initial est payant. À long terme, vous économiserez beaucoup de temps, d'énergie et de frustration.

Utilisabilité et accessibilité

La dernière raison que j'ai entendue est super valable. Le Web ne dispose pas d'une "bibliothèque standard" très solide lorsqu'il s'agit de choses comme les modales, les listes déroulantes et les infobulles. Construire une modale qui fonctionne bien pour les utilisateurs de souris, de clavier et de lecteurs d'écran est incroyablement difficile.

Les frameworks d'interface utilisateur ont un bilan mitigé en matière de convivialité et d'accessibilité. Certaines bibliothèques sont en fait assez bonnes à cet égard. Mais dans la plupart des cas, il s'agit d'une préoccupation secondaire.

Heureusement, il existe une autre catégorie d'outils qui se concentrent exclusivement sur la convivialité et l'accessibilité, sans prescrire un tas de styles.

Voici quelques-uns de mes outils préférés dans cette catégorie :

• Reach UIUn ensemble de primitives axées sur l'accessibilité pour React. Construit par Ryan Florence, co-créateur de React Router et Remix.
• Headless UIUn ensemble de composants d'interface utilisateur non stylisés et entièrement accessibles pour React et Vue. Construit et maintenu par l'équipe Tailwind.
• Radix PrimitivesUn ensemble de composants non stylisés et axés sur l'accessibilité pour React. Cette bibliothèque possède un ensemble très large de composants inclus, beaucoup de choses vraiment intéressantes !
• React ARIAUne bibliothèque de crochets React que vous pouvez utiliser pour construire des composants accessibles à partir de zéro.

Note : Je réalise que cette liste est très chargée en React ; il peut y avoir des outils similaires pour Angular, Svelte, et d'autres frameworks, mais je ne suis pas aussi actif dans ces communautés, donc je ne suis pas sûr. N'hésitez pas à m'en faire part sur Twitter si vous en connaissez !

Personne ne devrait construire une modale à partir de zéro en l'an 2022, mais cela ne signifie pas que vous ayez besoin d'un énorme framework d'interface utilisateur incluant des styles ! Il existe des outils qui résolvent précisément les défis d'accessibilité les plus importants tout en restant totalement agnostiques en matière de cosmétique et de styles.

Réfutations

Ça fait maintenant quelques années que je discute de ce sujet avec des développeurs, et j'ai entendu des réfutations assez convaincantes.

Familiarité

Tout d'abord, Daniel Schutzsmith a souligné que les outils "standard de l'industrie" comme Bootstrap ont un gros avantage : la familiarité.

Il est plus facile d'intégrer de nouveaux développeurs et designers lorsqu'on utilise des outils largement compris. Les nouveaux membres de l'équipe n'ont pas besoin de passer un temps fou à apprendre les tenants et aboutissants d'un framework personnalisé, ils peuvent être opérationnels dès le départ.

Du point de vue d'une agence qui prend de nombreux projets de court ou moyen terme, cela pourrait avoir beaucoup de sens. Ils n'ont pas besoin de démarrer chaque nouveau projet à partir de zéro. Et au fur et à mesure que l'équipe se familiarise avec l'outil, elle apprend à l'utiliser très efficacement.

Je n'ai pas beaucoup travaillé en agence, il m'est donc difficile de me prononcer. J'ai passé la majeure partie de ma carrière à travailler pour des entreprises de produits. Aucune des entreprises pour lesquelles j'ai travaillé n'a jamais utilisé un framework d'interface utilisateur. Nous avons toujours construit quelque chose en interne (par exemple, Wonder Blocks chez Khan Academy, ou Walrus chez DigitalOcean).

Outils internes

Je pense qu'il peut être judicieux d'utiliser un framework d'interface utilisateur lors de la création d'outils internes ou d'autres projets non destinés à la consommation publique (par exemple, des prototypes).

Si le but est de mettre rapidement quelque chose en place et de le faire fonctionner, et que vous n'avez pas besoin que l'interface utilisateur soit 100% professionnelle, je pense que cela peut être un gain de temps d'intégrer rapidement un tas de composants tiers.

Quid de Tailwind et de Chakra UI ?

Je ne considère pas Tailwind ou Chakra UI comme faisant partie de cette même catégorie de "frameworks UI".

Tailwind ne fournit pas de composants prêts à l'emploi, mais il fournit des garanties de design. Comme le dit Max Stoiber, Tailwind donne aux développeurs un ensemble de garde-fous. Vous avez toujours besoin d'une intuition de conception pour l'utiliser efficacement, mais ce n'est pas aussi intimidant que de concevoir quelque chose à partir de zéro.

Chakra UI fournit des composants stylisés prêts à l'emploi, mais ils sont très minimes et de bas niveau. La plupart du temps, ils ressemblent simplement à des versions plus agréables des paramètres par défaut de la plate-forme.

Ma bonne amie Emi m'a dit qu'elle aimait utiliser Chakra UI parce qu'il lui fournit un ensemble de valeurs par défaut raisonnables pour des choses comme les cases à cocher et les boutons radio. Elle est suffisamment douée en matière de conception pour éviter les pièges de la personnalisation, mais pas assez pour se sentir à l'aise pour créer tout un système de design à partir de zéro. Cet outil est le juste milieu idéal pour une personne dans sa situation.

Je pense que la différence est que ces solutions ne prétendent pas résoudre le design pour vous. Elles vous poussent dans la bonne direction, mais elles s'assurent que tout est personnalisable et que vous n'êtes pas enfermé dans une esthétique de design spécifique.

Ma suggestion alternative

Donc, si vous êtes un développeur solo qui veut créer des sites Web et des applications d'aspect professionnel, mais qui n'a pas de formation en design, que devez-vous faire ?

J'ai quelques suggestions.

Développez une intuition du design

Voici la mauvaise nouvelle : je pense que vous devriez consacrer un peu de temps à l'apprentissage de certains principes fondamentaux du design.

C'est l'une de ces choses pour lesquelles un petit peu suffit. Vous n'avez pas besoin d'aller dans une école d'art ou de consacrer des années à l'apprentissage d'un nouveau métier. Le design est difficile, mais nous n'essayons pas de devenir des designers de classe mondiale. Nos objectifs sont beaucoup plus modestes, et vous pourriez être surpris par la rapidité avec laquelle ils peuvent être atteints, ou par le chemin que vous avez déjà parcouru !

Même si vous n'êtes pas très intéressé par le design, je pense que développer une intuition de design est une compétence essentielle pour les développeurs front. Croyez-le ou pas, nous prenons constamment des décisions de design dans notre travail. Même à la maquette haute-fidélité la plus détaillée il manque toujours d'une tonne de contexte important.

Par exemple :

• Si nous avons de la chance, on peut nous donner 3 tailles d'écran, mais c'est à nous de décider comment l'interface utilisateur doit se comporter entre ces tailles d'écran.
• Les données sont rarement aussi propres qu'elles apparaissent dans les maquettes, et nous devons décider comment gérer les longs noms, les données manquantes, etc.
• Les états de chargement, de données manquantes et d'erreur sont souvent absents des maquettes.

L'un de mes super-pouvoirs en tant que développeur est d'avoir suffisamment de sens du design pour pouvoir déterminer ce qu'il faut faire lorsque je me heurte à une situation qui n'est pas clairement spécifiée dans le design. Au lieu d'être bloqué, en attendant que le designer réponde à mes questions, je peux me fier à mon intuition. Je n'y arriverai pas toujours, mais c'est généralement le cas (et lorsque ce n'est pas le cas, c'est une nouvelle occasion d'améliorer mon intuition en matière de design !)

Comment développer une intuition de design ?

Si vous travaillez avec une équipe de produit/design, vous disposez d'une ressource formidable ! Réfléchissez de manière critique aux conceptions qu'ils produisent. Posez beaucoup de questions — la plupart des designers seront ravis de vous aider à comprendre comment les choses sont structurées, et pourquoi ils ont pris les décisions qu'ils ont prises. Traitez-le comme un défi d'ingénierie. Vous pouvez apprendre les systèmes et les processus qui mènent à de bons designs.

J'ai écrit un article de blog il y a quelque temps, intitulé "Collaboration efficace avec le produit et le design". Il approfondit certaines de ces idées.

Si vous ne travaillez pas avec des designers (ou n'avez pas d'amis designers), vous pouvez essayer de faire de l'ingénierie inverse sur les produits que vous utilisez tous les jours. Prenez note de la façon dont les choses sont espacées, et des tailles de police utilisées. Avec un œil critique, vous commencerez à voir apparaître des patterns.

Volez

D'accord, même avec un sens aigu du design, il est toujours très difficile de créer un design à partir de rien. Alors, ne faisons pas cela.

Essayons plutôt de trouver des designs professionnels qui sont similaires à ce que nous essayons de construire. Vous pouvez faire des recherches sur des sites communautaires de designers comme dribbble ou behance ou utiliser des archives comme awwwards.

Par exemple, disons que nous créons une startup Uber pour chiens, et que nous essayons de concevoir le tableau de bord du conducteur. Une recherche sur Dribbble pour "dashboard" fait apparaître une tonne de designs intéressants :

Dribbble a tendance à être très "design", et vous pourriez donc vouloir utiliser des produits du monde réel pour vous inspirer. Ça fonctionne aussi !

L'astuce consiste à utiliser plusieurs sources. Si vous volez 100 % d'un design, c'est du plagiat et une mauvaise forme. Les gens vont le remarquer, et ça posera des problèmes.

Au lieu de ça, on peut mélanger 3 ou 4 designs ensemble pour créer quelque chose d'unique. Par exemple, je vais peut-être prendre le schéma de couleurs d'un site, la disposition générale et l'espacement d'un autre, et les styles de typographie du troisième !

Lorsque j'ai mentionné cette stratégie à de vrais designers, ils ont ri et m'ont dit que c'est ce qu'ils font tous. Je pense que c'est leur version de la "blague" selon laquelle les programmeurs passent la moitié de leur temps à googler des choses.

Cette stratégie ressemble à un véritable life hack. Elle ne se fait pas sans effort, et elle exige quelques compétences en matière de design. Les modèles que vous utilisez pour vous inspirer ne correspondront pas à 100 % à l'objet que vous construisez, et vous devrez faire appel à votre intuition pour combler les lacunes. Mais c'est de loin le moyen le plus rapide que j'ai trouvé pour créer un design d'aspect professionnel sans avoir de formation en design.

En résumé

En tant que développeurs, il peut être tentant de croire qu'un framework d'interface utilisateur nous dispensera d'apprendre quoi que ce soit sur le design. Malheureusement, cela ne se passe généralement pas ainsi. Du moins, pas d'après ce que j'ai vu.

Voici la bonne nouvelle : vous pouvez tout à fait créer un produit d'aspect professionnel sans être designer ! Avec quelques modèles de référence de haute qualité et un soupçon d'intuition en matière de design, vous pouvez construire quelque chose qui atteint le seuil du "suffisamment bon", où un produit semble légitime et "réel".

Il y a un autre aspect dont nous n'avons pas vraiment parlé : CSS.

Beaucoup de développeurs front ont du mal avec CSS. Moi aussi, j'ai eu du mal à m'y mettre ! CSS est un langage faussement complexe, et il peut souvent sembler incohérent et frustrant, même après avoir des années d'expérience avec le langage.

C'est un problème qui me tient à cœur. J'ai passé toute l'année dernière à me consacrer à plein temps à la création et au développement d'un cours CSS, afin d'aider les développeurs à gagner en confiance avec ce langage.

Il s'appelle CSS pour les développeurs JavaScript. Il est conçu spécifiquement pour les personnes qui utilisent un framework JS comme React ou Angular. Le cours vise à vous donner un modèle mental robuste afin que vous ayez une compréhension intuitive du fonctionnement de CSS.

Si vous avez l'impression que CSS est imprévisible, j'espère vraiment que vous le consulterez. Plus de 9.000 développeurs ont déjà suivi le cours, et les retours ont été extrêmement positifs.

Vous pouvez en savoir plus ici : css-for-js.dev.

Dans l'article précédent, nous avons vu comment améliorer l'accessibilité pour les utilisateurs de clavier grâce à HTML et CSS. Ces langages peuvent faire le job la plupart du temps, mais certaines contraintes de design et la nature même de certains composants nécessitent des interactions plus complexes, et c'est là que JavaScript entre en jeu.

Quand on parle d'accessibilité clavier, le travail se fait essentiellement avec des outils de base. Cet article couvre un ensemble d'outils que vous pouvez utiliser de pair avec différents composants afin d'améliorer l'accessibilité pour les utilisateurs du clavier.

Les bases

Notre travail avec JavaScript se fera généralement avec une poignée d'outils seulement, en particulier l'utilisation d'event listeners (écouteurs d'événements) et de certaines méthodes JavaScript de quelques API Web qui peuvent nous aider dans cette tâche.

Pour ajouter de l'interactivité à nos projets, l'un des outils les plus importants à notre disposition est l'événement, c'est-à-dire l'exécution d'une fonction qui se déclenche lorsque l'élément que nous contrôlons reçoit un changement.

Événement keydown

Un exemple d'événement que nous pouvons écouter avec cette API Web est l'événement keydown, qui vérifie quand une touche (key) est enfoncée.

Cet événement n'est pas utile pour ajouter l'accessibilité du clavier à des éléments tels que les boutons ou les liens car, par défaut, lorsque nous leur ajoutons un event listener de clic, celui-ci déclenche également l'événement lorsque nous utilisons les touches Entrée (pour les boutons et les liens) et Espace (pour les boutons uniquement). L'utilité de l'événement keydown apparaît lorsque nous devons ajouter une fonctionnalité à d'autres touches.

Pour prendre un exemple, revenons à l'infobulle que nous avons créée dans la première partie de cet article. J'ai mentionné que cette infobulle devait être fermée lorsque nous appuyons sur la touche Esc. Nous aurions besoin d'un event listener de touche enfoncée afin de vérifier si la touche enfoncée est Esc. Pour cela, nous devons détecter la touche enfoncée de l'événement et nous allons donc vérifier la propriété de la touche de l'événement.

Nous utiliserons keycode.info pour vérifier le dump d'événement pour cette touche. Si vous appuyez sur la touche Esc sur votre clavier, vous remarquerez que e.key (event.key) est égal à Escape.

Remarque : Il existe deux autres façons de détecter qu'une touche est enfoncée, ce sont la vérification de e.keyCode et e.which qui renvoient toutes deux un nombre. Dans le cas de la touche Esc, ce sera 27 (qui est affiché en gros dans la page). Mais gardez à l'esprit qu'il s'agit de solutions alternatives dépréciées, et que même si elles fonctionnent, e.key est aujourd'hui l'option préférée.

Avec cela, nous devons sélectionner nos boutons et ajouter l'event listener. Mon approche en la matière est d'utiliser cet event listener pour ajouter une classe au bouton et d'ajouter cette classe comme exception afin de l'afficher en utilisant la pseudo-classe de négation :not(). Commençons en modifiant un peu notre CSS :

button:not(.hide-tooltip):hover + [role='tooltip'],
button:not(.hide-tooltip):focus + [role='tooltip'],
[role='tooltip']:hover {
  display: block;
}

Cette exception étant ajoutée, créons maintenant notre event listener !

const buttons = [...document.querySelectorAll('button')]
buttons.forEach((element) => {
  element.addEventListener('keydown', (e) => {
    if (e.key === 'Escape') {
      element.classList.add('hide-tooltip')
    }
  })
})

Et voilà ! Avec juste un soupçon de JavaScript, nous avons ajouté une fonction d'accessibilité à notre infobulle. Et ce n'était que le début de ce que nous pouvons faire avec un event listener keydown. C'est un outil crucial pour améliorer l'accessibilité au clavier de plusieurs composants. Mais il existe encore un autre event listener que nous devons prendre en considération.

L'événement blur

Il ya un autre événement que nous allons utiliser souvent. Celui-ci détecte le moment où l'élément cesse de recevoir le focus. Cet event listener est important, la plupart du temps vous l'utiliserez pour annuler les éventuelles modifications que vous avez apportées avec l'event listener keydown.

Revenons à l'infobulle. Pour l'instant, elle présente un problème : si vous appuyez sur la touche Esc pour fermer l'infobulle, puis que vous mettez à nouveau le focus sur le même élément, l'infobulle n'apparaîtra pas. Pourquoi ? Parce que nous avons ajouté la classe hide-tooltip lorsque l'utilisateur appuie sur la touche Esc, mais nous n'avons jamais supprimé cette classe. C'est ici que le blur (flou) entre en jeu. Ajoutons un event listener pour rétablir cette fonctionnalité.

element.addEventListener('blur', (e) => {
  if (element.classList.contains('hide-tooltip')) {
    element.classList.remove('hide-tooltip')
  }
})

Autres Event Listeners (et pourquoi vous n'en avez peut-être pas besoin)

J'ai mentionné que nous aurions besoin de deux event listeners dans notre boîte à outils, mais il en existe d'autres que vous pourriez utiliser, comme focusout ou focus. Cependant, je pense que les cas d'utilisation pour eux sont assez rares. Mention spéciale pour focus toutefois car même si vous pouvez trouver de bons cas d'utilisation pour lui, vous devez être très prudent : si vous ne l'utilisez pas correctement, vous pouvez provoquer un changement de contexte.

Un changement de contexte est défini par les WCAG comme "des changements majeurs qui, s'ils sont effectués sans que l'utilisateur en soit conscient, peuvent désorienter les utilisateurs qui ne sont pas en mesure de visualiser la page entière simultanément." Voici quelques exemples de changements de contexte :

• L'ouverture d'une nouvelle fenêtre ;
• Une modification importante de la mise en page de votre site ;
• Un déplacement du centre d'intérêt vers une autre partie du site.

Il est important de garder tout cela à l'esprit, car la création d'un changement de contexte au moment où l'on se concentre sur un élément constitue un manquement au critère 3.2.1 des WCAG :

Si vous ne faites pas attention, une mauvaise utilisation d'une fonction qui écoute l'événement focus peut créer un changement de contexte. Cela signifie-t-il que vous ne devriez pas l'utiliser ? Pas vraiment, mais pour être honnête, j'ai du mal à trouver une utilité à cet événement. La plupart du temps, vous utiliserez la pseudo-classe :focus pour créer des fonctionnalités similaires.

Cela dit, il existe tout de même au moins un modèle de composant qui peut bénéficier de cet écouteur d'événements dans certains cas, mais je le couvrirai plus tard lorsque je commencerai à parler des composants, alors mettons ce sujet en veilleuse pour l'instant.

Méthode focus()

Ah, voici une méthode que nous allons utiliser assez fréquemment ! Cette méthode de l'API HTMLElement nous permet d'attirer l'attention du clavier sur un élément particulier. Par défaut, elle dessine l'indicateur de focus dans l'élément et fait défiler la page jusqu'à l'emplacement de l'élément. Ce comportement peut être modifié à l'aide de quelques paramètres :

• preventScroll :Lorsqu'il a la valeur true, le navigateur ne défile pas jusqu'à l'élément sur lequel le focus est programmé.
• focusVisible :Lorsqu'il est réglé sur false, l'élément programmatiquement ciblé n'affiche pas son indicateur de ciblage. Cette propriété ne fonctionne pour l'instant que sur Firefox.

Gardez à l'esprit que pour mettre l'accent sur l'élément, celui-ci doit pouvoir être focusé ou tabulé. Si vous devez mettre l'accent sur un élément normalement non tabulable (comme une fenêtre de dialogue), vous devrez ajouter l'attribut tabindex avec un nombre entier négatif pour le rendre focalisable. Vous pouvez vérifier le fonctionnement de tabindex dans la première partie de ce guide.

<button id="openModal">Bring focus</button>
<div id="modal" role="dialog" tabindex="-1">
  <h2>Modal content</h2>
</div>

Puis nous ajouterons un écouteur d'événement de clic au bouton pour que la fenêtre de dialogue soit focalisée :

const button = document.querySelector('#openModal')
const modal = document.querySelector('#modal')
button.addEventListener('click', () => {
  modal.focus()
})

Et voilà ! Cette méthode sera très pratique dans de nombreux composants en tandem avec l'attribut keydown, il est donc crucial de comprendre comment les deux fonctionnent.

Modifier les attributs HTML avec JavaScript

Certains attributs HTML doivent être modifiés avec JavaScript pour créer l'accessibilité dans des modèles de composants complexes. Deux des plus importants pour l'accessibilité du clavier sont tabindex et le plus récemment ajouté inert. tabindex peut être modifié en utilisant setAttribute. Cet attribut requiert deux paramètres :

• nameIl vérifie le nom de l'attribut que vous souhaitez modifier.
• valueIl ajoute la chaîne de caractères que cet attribut requiert s'il ne requiert pas un attribut particulier (par exemple, si vous ajoutez les attributs hidden ou contenteditable, vous devrez utiliser une chaîne vide).

Voyons un exemple rapide de son utilisation :

const button = document.querySelector('button')
button.setAttribute('tabindex', '-1')

setAttribute est très utile pour l'accessibilité en général (je l'utilise souvent pour modifier les attributs ARIA en cas de besoin !). Mais, lorsque nous parlons d'accessibilité au clavier, tabindex est à peu près le seul attribut que vous modifierez avec cette méthode.

J'ai mentionné l'attribut inert auparavant, et celui-ci fonctionne un peu différemment car il possède sa propre propriété dans l'API Web HTMLElement. HTMLElement.inert est une valeur booléenne qui nous permet de basculer l'attribut inert.

Gardez à l'esprit deux choses avant d'utiliser cet attribut :

• Vous aurez besoin d'un polyfill car il n'est pas entièrement implémenté dans tous les navigateurs et est encore assez récent. Ce polyfill créé par les ingénieurs de Chrome fonctionne plutôt bien dans les tests que j'ai effectués, donc si vous avez besoin de cette propriété, c'est une approche sûre, mais gardez à l'esprit qu'elle pourrait avoir des comportements inattendus.
• Vous pouvez également utiliser setAttribute pour modifier cet attribut ! Les deux fonctionnent aussi bien, même avec un polyfill. C'est à vous de décider entre les deux.

const button = document.querySelector('button')
// Syntaxe avec HTMLElement.inert
button.inert = true
// Syntaxe avec Element.setAttribute()
button.setAttribute('inert', '')

Cette combinaison d'outils sera très pratique pour l'accessibilité du clavier. Commençons maintenant à les voir en action !

Patterns de composants

Toggletips

Nous avons appris à créer une infobulle dans la partie précédente, et j'ai mentionné comment l'améliorer avec JavaScript, mais il existe un autre modèle pour ce type de composant appelé toggletip, qui est une infobulle fonctionnant avec un clic, plutôt qu'au survol.

Dressons une liste rapide de ce dont nous avons besoin pour que cela se produise :

• Lorsque vous appuyez sur le bouton, les informations doivent être annoncées aux lecteurs d'écran. Cela devrait se produire lorsque vous appuyez à nouveau sur le bouton. Appuyer sur le bouton ne fermera pas le toggletip.
• Le toggletip sera fermé lorsque vous cliquerez à l'extérieur du toggletip, que vous cesserez de focaliser le bouton ou que vous appuierez sur la touche Esc.

Je vais adopter l'approche de Heydon Pickering dont il parle dans son livre Inclusive Components. Commençons donc par le balisage :

<p>
  If you need to check more information, check here
  <span class="toggletip-container">
    <button class="toggletip-button">
      <span class="toggletip-icon" aria-hidden="true">?</span>
      <div class="sr-only">Más información</div>
    </button>
    <span role="status" class="toggletip-info"></span>
  </span>
</p>

L'idée est d'injecter le HTML nécessaire à l'intérieur de l'élément avec le role="status". Cela permettra aux lecteurs d'écran d'annoncer le contenu lorsque vous cliquez dessus. Nous utilisons un élément button pour le rendre tabulable. Maintenant, créons le script pour afficher le contenu !

toggletipButton.addEventListener('click', () => {
  toggletipInfo.innerHTML = ''
  setTimeout(() => {
    toggletipInfo.innerHTML = toggletipContent
  }, 100)
})

Ceci fait, il est temps d'ajouter l'accessibilité clavier à ce composant. Il n'est pas nécessaire d'afficher le contenu du toggletip lorsque vous appuyez sur le bouton, car une bonne sémantique HTML le fait déjà pour nous. Nous devons faire en sorte que le contenu du toggletip cesse de s'afficher lorsque vous appuyez sur la touche Esc et lorsque vous cessez le focus sur ce bouton. Cela fonctionne de manière très similaire à ce que nous avons fait pour les info-bulles dans la section précédente à titre d'exemple, alors commençons à travailler avec cela. Tout d'abord, nous allons utiliser l'écouteur d'événements keydown pour vérifier quand la touche Esc est enfoncée :

toggletipContainer.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') {
    toggletipInfo.innerHTML = ''
  }
})

Et maintenant, nous devons vérifier l'événement blur pour faire la même chose. Celui-ci doit être sur l'élément bouton et non sur conteneur.

toggletipButton.addEventListener('blur', () => {
  toggletipInfo.innerHTML = ''
})

Et voilà le résultat !

voirToggletip demode smashingmag dansCodePen

Comme je l'ai mentionné, ça fonctionne de manière très similaire à l'infobulle que nous avons réalisée, mais je l'ai fait pour une bonne raison. À moins que vous ne fassiez quelque chose de très peu conventionnel, ces modèles se répéteront assez souvent.

Comme Stephanie Eckles le mentionne dans son article "4 tests obligatoires avant de livrer de nouvelles fonctionnalités", les utilisateurs du clavier s'attendent à certains comportements de la part des composants, comme la possibilité de fermer une fenêtre que vous venez d'ouvrir en appuyant sur la touche Esc, ou de naviguer dans un groupe d'options connexes à l'aide des touches fléchées.

Si vous gardez ces modèles à l'esprit, vous remarquerez des chevauchements dans les comportements de certains composants, et ça se répétera lorsque vous commencerez à créer du code JavaScript pour assurer l'accessibilité au clavier. Si vous gardez cette liste à l'esprit, vous comprendrez mieux les requis des composants que vous créez.

En parlant de ça, vérifions un autre modèle de composant commun.

Onglets

tabindex itinérant

Les interfaces à onglets sont des modèles que vous pouvez encore voir de temps en temps. Elles présentent une fonctionnalité très intéressante pour la navigation au clavier : lorsque vous appuyez sur la touche Tab, vous accédez au panneau d'onglets actif. Pour naviguer dans la liste des onglets, vous devrez utiliser les touches fléchées. Il s'agit d'une technique appelée "tabindex itinérant" qui consiste à supprimer la capacité des éléments non actifs à être tabulables en ajoutant l'attribut tabindex="-1", puis à utiliser d'autres touches pour permettre la navigation entre ces éléments.

Avec les onglets, c'est le comportement attendu pour ceux-ci :

• Lorsque vous appuyez sur les touches Flèche vers la gauche ou 'Flèche vers le haut`, cela déplace le focus du clavier sur l'onglet précédent. Si le focus est sur le premier onglet, le focus sera déplacé sur le dernier onglet.
• Lorsque vous appuyez sur les touches Flèche vers la droiteouFlèche vers le bas, le focus du clavier est déplacé vers l'onglet suivant. Si le focus est sur le premier onglet, le focus est déplacé vers le dernier onglet. La création de cette fonctionnalité est un mélange de trois techniques que nous avons vues précédemment : la modification de tabindex avec setAttribute, l'écouteur d'événement keydownet la méthodefocus(). Commençons par vérifier le balisage de ce composant :

<ul role="tablist">
  <li role="presentation">
    <button id="tab1" role="tab" aria-selected="true">Tomato</button>
  </li>
  <li role="presentation">
    <button id="tab2" role="tab" tabindex="-1">Onion</button>
  </li>
  <li role="presentation">
    <button id="tab3" role="tab" tabindex="-1">Celery</button>
  </li>
  <li role="presentation">
    <button id="tab4" role="tab" tabindex="-1">Carrot</button>
  </li>
</ul>
<div class="tablist-container">
  <section
    role="tabpanel"
    aria-labelledby="tab1"
    tabindex="0"
  ></section>
  <section
    role="tabpanel"
    aria-labelledby="tab2"
    tabindex="0"
    hidden
  ></section>
  <section
    role="tabpanel"
    aria-labelledby="tab3"
    tabindex="0"
    hidden
  ></section>
  <section
    role="tabpanel"
    aria-labelledby="tab4"
    tabindex="0"
    hidden
  ></section>
</div>

Nous utilisons aria-selected="true" pour montrer quel est l'onglet actif, et nous ajoutons tabindex="-1" pour que les onglets non actifs ne puissent pas être sélectionnés avec la touche Tab. Les onglets doivent pouvoir être sélectionnés s'il n'y a pas d'élément tabulable à l'intérieur, c'est pourquoi j'ai ajouté l'attribut tabindex="0" et les onglets inactifs sont masqués à l'aide de l'attribut hidden.

Il est temps d'ajouter la navigation avec les touches fléchées. Pour cela, nous devrons créer un tableau avec les onglets et ensuite créer une fonction pour celui-ci. Notre prochaine étape consiste à vérifier quel est le premier et le dernier onglet de la liste. C'est important car l'action qui se produira lorsque vous appuierez sur une touche changera si le focus du clavier est sur l'un de ces éléments.

const TABS = [...TABLIST.querySelectorAll("[role='tab']")]
const createKeyboardNavigation = () => {
  const firstTab = TABS[0]
  const lastTab = TABS[TABS.length - 1]
}

Après cela, nous ajouterons un écouteur d'événement keydown à chaque onglet. Je vais commencer par ajouter la fonctionnalité des flèches gauche et haut.

// Previous code of the createKeyboardNavigation function
TABS.forEach((element) => {
  element.addEventListener("keydown", function (e) {
    if (e.key === "ArrowUp" || e.key === "ArrowLeft") {
      e.preventDefault();
      if (element === firstTab) {
        lastTab.focus();
      } else {
        const focusableElement = TABS.indexOf(element) - 1;
        TABS[focusableElement].focus();
      }
    }
  }
}

Voici ce qui se passe ici :

• Tout d'abord, nous vérifions que la touche pressée est la flèche Haut ou Gauche. Pour cela, nous vérifions l'event.key.
• Si c'est vrai, nous devons empêcher ces touches de faire défiler la page car, rappelez-vous, par défaut, elles le font. Nous pouvons utiliser e.preventDefault() dans ce but.
• Si la touche focalisée est le premier onglet, le focus clavier sera automatiquement porté sur le dernier onglet. Cela se fait en appelant la méthode focus() pour focaliser le dernier onglet (que nous stockons dans une variable).
• Si ce n'est pas le cas, nous devons vérifier la position de l'onglet actif. Comme nous stockons les éléments de l'onglet dans un tableau, nous pouvons utiliser la méthode indexOf() pour vérifier sa position.
• Comme nous essayons de naviguer vers l'onglet précédent, nous pouvons soustraire 1 du résultat de indexOf(), puis rechercher l'élément correspondant dans le tableau TABS et le focaliser de manière programmatique avec la méthode focus().

Nous devons maintenant effectuer un processus très similaire avec les touches Flèche vers le bas et Flèche vers la droite :

// Code précédent de la fonction createKeyboardNavigation
else if (e.key === "ArrowDown" || e.key === "ArrowRight") {
  e.preventDefault();
  if (element == lastTab) {
    firstTab.focus();
  } else {
    const focusableElement = TABS.indexOf(element) + 1;
    TABS[focusableElement].focus();
  }
}

Comme je l'ai mentionné, il s'agit d'un processus très similaire. Au lieu de soustraire 1 au résultat de indexOf(), nous ajoutons 1 car nous voulons amener le focus du clavier sur l'élément suivant.

Affichage du contenu et modification des attributs HTML

Nous avons créé la navigation, et maintenant nous devons afficher et masquer le contenu ainsi que manipuler les attributs aria-selected et tabindex. Rappelez-vous, nous devons faire en sorte que lorsque le focus du clavier est sur le panneau actif, et que vous appuyez sur Shift + Tab, le focus doit être dans l'onglet actif.

Tout d'abord, créons la fonction qui affiche le panneau :

const showActivePanel = (element) => {
  const selectedId = element.target.id
  TABPANELS.forEach((e) => {
    e.hidden = 'true'
  })
  const activePanel = document.querySelector(
    `[aria-labelledby="${selectedId}"]`
  )
  activePanel.removeAttribute('hidden')
}

Ce que nous faisons ici, c'est vérifier que l'id de l'onglet est pressé, puis masquer tous les panneaux d'onglets, et enfin rechercher le panneau d'onglet que nous voulons activer. Nous saurons qu'il s'agit de l'onglet car il possède l'attribut aria-labelledby et utilise la même valeur que l'id de l'onglet. Ensuite, nous l'affichons en supprimant l'attribut hidden.

Maintenant, nous devons créer une fonction pour modifier les attributs :

const handleSelectedTab = (element) => {
  const selectedId = element.target.id
  TABS.forEach((e) => {
    const id = e.getAttribute('id')
    if (id === selectedId) {
      e.removeAttribute('tabindex', '0')
      e.setAttribute('aria-selected', 'true')
    } else {
      e.setAttribute('tabindex', '-1')
      e.setAttribute('aria-selected', 'false')
    }
  })
}

Ce que nous faisons ici, c'est, encore une fois, vérifier l'attribut id et ensuite regarder chaque onglet. Nous allons vérifier si l'id de cet onglet correspond à l'id de l'élément pressé.

Si c'est le cas, nous le rendrons tabulable par le clavier soit en supprimant l'attribut tabindex (parce que c'est un bouton, donc par défaut il est tabulable par le clavier), soit en ajoutant l'attribut tabindex="0". En outre, nous ajouterons un indicateur aux utilisateurs de lecteurs d'écran qu'il s'agit de l'onglet actif en ajoutant l'attribut aria-selected="true".

Si cela ne correspond pas, tabindex et aria-selected seront respectivement définis à -1 et false.

Maintenant, il ne nous reste plus qu'à ajouter un écouteur d'événements de clics à chaque onglet pour gérer les deux fonctions.

TABS.forEach((element) => {
  element.addEventListener('click', (element) => {
    showActivePanel(element), handleSelectedTab(element)
  })
})

Et c'est tout ! Nous avons créé la fonctionnalité pour faire fonctionner les onglets, mais nous pouvons faire un petit quelque chose d'autre si nécessaire.

Activer l'onglet sur le focus

Vous vous souvenez de ce que j'ai souligné à propos de l'écouteur d'événement de focus ? Vous devez être prudent lorsque vous l'utilisez car il peut créer un changement de contexte par accident. Cependant, il a une certaine utilité, et ce composant est une occasion parfaite de l'utiliser !

Selon le guide des pratiques de création ARIA (APG), nous pouvons faire en sorte que le contenu affiché s'affiche lorsque vous mettez le focus sur l'onglet. Ce concept est souvent appelé "follow focus" (suivre le focus) et peut être utile aux utilisateurs de claviers et de lecteurs d'écran car il permet de naviguer plus facilement dans le contenu.

Toutefois, vous devez tenir compte de quelques considérations à ce sujet :

Si afficher le contenu signifie faire beaucoup de requêtes et, par extension, rendre le réseau plus lent, faire en sorte que le contenu affiché suive le focus n'est pas souhaité.Si cela modifie la mise en page de manière significative, on peut le considérer comme un changement de contexte. Ça dépend du type de contenu que vous voulez afficher, et faire un changement de contexte sur le focus est un problème d'accessibilité, comme je l'ai expliqué précédemment.Dans le cas présent, la quantité de contenu ne suppose pas un grand changement, ni au niveau du réseau, ni à celui de la mise en page, je vais donc faire en sorte que le contenu affiché suive le focus des onglets. C'est une tâche très simple avec l'écouteur d'événement focus. Nous pouvons littéralement copier et coller l'écouteur d'événements que nous avons créé et simplement changer le clic en focus.

TABS.forEach((element) => {
  element.addEventListener('click', (element) => {
    showActivePanel(element), handleSelectedTab(element)
  })
  element.addEventListener('focus', (element) => {
    showActivePanel(element), handleSelectedTab(element)
  })
})

Et voilà, c'est fait ! Maintenant, le contenu affiché fonctionnera sans qu'il soit nécessaire de cliquer sur l'onglet. Le choix vous revient (clic ou pas clic) et c'est étonnamment une question très nuancée. Personnellement, je m'en tiendrais à ce que cela s'affiche lorsque vous appuyez sur l'onglet car je pense que l'expérience de modifier l'attribut aria-selected en se concentrant simplement sur l'élément peut être légèrement déroutante. Mais ce n'est qu'une hypothèse de ma part, alors prenez ce que je dis avec un grain de sel et vérifiez toujours avec les utilisateurs.

Écouteurs d'événements keydown supplémentaires

Revenons un instant sur le createKeyboardNavigation. Il y a quelques touches que nous pouvons ajouter. Nous pouvons faire en sorte que les touches Home et End amènent le focus du clavier sur le premier et le dernier onglet, respectivement. C'est complètement facultatif, donc ce n'est pas grave si vous ne le faites pas, mais juste pour rappeler l'utilité d'un écouteur d'événements de touche, je vais le faire.

C'est une tâche très facile. Nous pouvons créer une autre paire d'instructions if pour vérifier si les touches Home et End sont enfoncées, et comme nous avons stocké le premier et le dernier onglet dans des variables, nous pouvons les mettre au point avec la méthode focus().

// Code précédent de la fonction createKeyboardNavigation, puis:
else if (e.key === "Home") {
  e.preventDefault();
  firstTab.focus()
} else if (e.key === "End") {
  e.preventDefault();
  lastTab.focus()
}

...et voilà le résultat !

voirTab demode smashingmag dansCodePen

Avec ce code, nous avons rendu ce composant accessible aux utilisateurs de clavier et de lecteur d'écran. Cela montre à quel point les concepts de base de l'écouteur d'événement keydown, de la méthode focus() et des modifications que nous pouvons apporter avec setAttribute sont utiles pour manipuler des composants complexes. Voyons-en un autre, très compliqué, et comment l'attribut inert peut nous aider à gérer cette tâche facilement.

Ouvrir et fermer la modale

Les modales sont un pattern assez complexe quand on parle d'accessibilité au clavier, alors commençons par une tâche facile : ouvrir et fermer la modale.

C'est en effet facile, mais vous devez garder quelque chose à l'esprit : il est très probable que le bouton ouvre la modale, et la modale est loin dans le DOM. Vous devez donc gérer le focus de manière programmatique lorsque vous gérez ce composant. Il y a un petit piège ici : vous devez mémoriser quel élément a ouvert la modale pour pouvoir renvoyer le focus du clavier à cet élément au moment où nous le fermons.

Heureusement, il existe un moyen facile de le faire, mais commençons par créer le balisage de notre site :

<body>
  <header>
    <!-- Header's content -->
  </header>
  <main>
    <!-- Main's content -->
    <button id="openModal">Open modal</button>
  </main>
  <footer>
    <!-- Footer's content -->
  </footer>
  <div
    role="dialog"
    aria-modal="true"
    aria-labelledby="modal-title"
    hidden
    tabindex="-1"
  >
    <div class="dialog__overlay"></div>
    <div class="dialog__content">
      <h2 id="modal-title">Modal content</h2>
      <ul>
        <li><a href="#">Modal link 1</a></li>
        <li><a href="#">Modal link 2</a></li>
        <li><a href="#">Modal link 3</a></li>
      </ul>
      <button id="closeModal">Close modal</button>
    </div>
  </div>
</body>

Comme je l'ai mentionné, la modale et le bouton sont très éloignés l'un de l'autre dans le DOM. Il sera donc plus facile de créer un piège à focus plus tard, mais pour l'instant, vérifions la sémantique de la modale :

• role="dialog" donnera à l'élément la sémantique requise pour les lecteurs d'écran. Il doit avoir une étiquette pour être reconnu comme une fenêtre de dialogue, nous utiliserons donc le titre de la modale comme étiquette en utilisant l'attribut aria-labelledby.
• aria-modal="true" permet de faire en sorte qu'un utilisateur de lecteur d'écran ne puisse lire que le contenu des enfants de l'élément, ce qui bloque l'accès des lecteurs d'écran. Cependant, comme vous pouvez le voir sur la page aria-modal de a11ysupport.com, elle n'est pas entièrement prise en charge, donc vous ne pouvez pas vous fier uniquement à cela pour cette tâche. Elle sera utile pour les lecteurs d'écran qui la prennent en charge, mais vous verrez qu'il existe un autre moyen de s'assurer que les utilisateurs de lecteurs d'écran n'interagissent avec rien d'autre que la modale une fois qu'elle est ouverte.
• Comme je l'ai indiqué, nous devons amener le focus du clavier sur notre modale, c'est pourquoi nous avons ajouté l'attribut tabindex="-1".

Avec cela en tête, nous devons créer la fonction pour ouvrir notre modale. Nous devons vérifier quel est l'élément qui l'a ouverte, et pour cela, nous pouvons utiliser la propriété document.activeElement pour vérifier quel est l'élément qui a le focus sur le clavier en ce moment et le stocker dans une variable. C'est mon approche pour cette tâche :

let focusedElementBeforeModal
const modal = document.querySelector("[role='dialog']")
const modalOpenButton = document.querySelector('#openModal')
const modalCloseButton = document.querySelector('#closeModal')
const openModal = () => {
  focusedElementBeforeModal = document.activeElement
  modal.hidden = false
  modal.focus()
}

C'est très simple :

1. Nous stockons le bouton qui a ouvert la modale ;
2. Puis nous l'affichons en supprimant l'attribut hidden ;
3. Puis nous mettons le focus sur la modale avec la méthode focus().

Il est essentiel de stocker le bouton avant d'amener le focus sur la modale. Sinon, l'élément qui serait stocké dans ce cas serait la modale elle-même, et ce n'est pas ce que nous voulons.

Maintenant, nous devons créer la fonction pour fermer la modale :

const closeModal = () => {
  modal.hidden = true
  focusedElementBeforeModal.focus()
}

Voilà pourquoi il est important de stocker l'élément approprié. Lorsque nous fermerons la modale, nous ramènerons le focus clavier sur l'élément qui l'a ouverte. Avec ces fonctions créées, il ne nous reste plus qu'à ajouter les écouteurs d'événements pour ces fonctions ! N'oubliez pas que nous devons aussi faire en sorte que la modale se ferme lorsque nous appuyons sur la touche Esc.

modalOpenButton.addEventListener('click', () => openModal())
modalCloseButton.addEventListener('click', () => closeModal())
modal.addEventListener('keydown', (e) => {
  if (e.key === 'Escape') {
    closeModal()
  }
})

Pour l'instant, ça paraît très simple. Mais si c'était tout, les modales ne seraient pas considérées comme un modèle complexe pour l'accessibilité, n'est-ce pas ? C'est là que nous devons créer une tâche très importante pour ce composant, et nous avons deux façons de le faire.

Création d'un piège à focus

Un piège à focus garantit que le focus clavier ne peut pas s'échapper du composant. C'est crucial car si un utilisateur du clavier peut interagir avec quoi que ce soit en dehors d'une modale une fois qu'elle est ouverte, cela peut créer une expérience très déroutante. Nous disposons actuellement de deux moyens pour y parvenir.

L'une d'entre elles consiste à vérifier chaque élément qui peut être tabulé avec un clavier, puis à mémoriser lesquels sont le premier et le dernier, et à faire ceci :

• Lorsque l'utilisateur appuie sur Shift + Tab et que le focus du clavier est sur le premier élément tabulable (rappelez-vous, vous pouvez vérifier cela avec document.activeElement), le focus ira sur le dernier élément tabulable.
• Lorsque l'utilisateur appuie sur Tab, et que le focus du clavier est sur le dernier élément tabulable, le focus du clavier devrait aller sur le premier élément tabulable.

Normalement, je vous aurais montré comment faire ce code, mais je pense que les solutions A11y ont fait un très bon script pour créer un piège à focus. Il fonctionne en quelque sorte comme la navigation au clavier avec les touches fléchées que nous avons créées pour les éléments tabulables (comme je l'ai déjà mentionné, les motifs se répètent !), je vous invite donc à consulter cette page.

Je ne veux pas utiliser cette approche comme solution principale, car elle n'est pas exactement sans défaut. Il y a certaines situations que cette approche ne couvre pas.

La première est qu'elle ne prend pas en compte les lecteurs d'écran, notamment les lecteurs d'écran mobiles. Comme le mentionne Rahul Kumar dans son article "Focus Trapping for Accessibility (A11Y)", Talkback et Voiceover permettent à l'utilisateur de faire des gestes et des doubles tapotements pour naviguer vers l'élément focalisable suivant ou précédent, et ces gestes ne peuvent pas être détectés avec un écouteur d'événements car ces gestes, techniquement parlant, ne se produisent pas dans le navigateur. Il existe une solution à ce problème, mais je vais mettre ce sujet en suspens pendant un moment.

L'autre préoccupation est que cette approche de piège à focus peut conduire à des comportements bizarres si vous utilisez certaines combinaisons d'éléments tabulables. Prenez, par exemple, cette modale :

Techniquement parlant, le premier élément tabulable est le premier input. Cependant, toutes les entrées de cet exemple doivent se concentrer sur le dernier élément tabulable (dans ce cas, l'élément bouton) lorsque l'utilisateur appuie sur les touches Shift + Tab. Sinon, cela pourrait provoquer un comportement bizarre si l'utilisateur appuie sur ces touches alors que le focus du clavier est sur le deuxième ou troisième input.

Si nous voulons créer une solution plus fiable, la meilleure approche consiste à utiliser l'attribut inert pour rendre le contenu externe inaccessible aux lecteurs d'écran et aux utilisateurs de clavier, en veillant à ce qu'ils puissent interagir uniquement avec le contenu de la modale. N'oubliez pas que cela nécessitera le polyfill inert pour ajouter plus de robustesse à cette technique.

Remarque : il est important de noter que malgré le fait qu'un piège à focus et l'utilisation d'inert contribuent en pratique à garantir l'accessibilité du clavier pour les modales, ils ne fonctionnent pas exactement de la même manière. La principale différence est que si vous définissez tous les documents, sauf la modale, comme inertes, vous pourrez toujours sortir du site Web et interagir avec les éléments du navigateur. C'est sans doute mieux pour des raisons de sécurité, mais c'est à vous de décider si vous voulez créer un piège à focus manuellement ou utiliser l'attribut inert.

Ce que nous allons faire d'abord, c'est sélectionner toutes les zones qui n'ont pas le rôle dialog. Comme l'attribut inert supprimera toute interaction du clavier et du lecteur d'écran avec les éléments et leurs enfants, nous devrons sélectionner uniquement les enfants directs de body. C'est pourquoi nous laissons le conteneur modal exister au même niveau que des balises comme main, header ou footer.

// Ce sélecteur fonctionne bien pour cette structure HTML spécifique. Adaptez-la selon votre projet.
const nonModalAreas = document.querySelectorAll(
  "body > *:not([role='dialog'])"
)

Nous devons maintenant revenir à la fonction openModal. Après avoir ouvert la modale, nous devons ajouter l'attribut inert à ces éléments. Ceci devrait être la dernière étape de la fonction :

const openModal = () => {
  // ici, le code ajouté précédemment
  nonModalAreas.forEach((element) => {
    element.inert = true
  })
}

Qu'en est-il lorsque vous fermez la modale ? Vous devez aller dans la fonction closeModal et supprimer cet attribut. Cela doit se faire avant l'exécution de tout le reste du code. Sinon, le navigateur ne sera pas en mesure de mettre le focus sur le bouton qui a ouvert cette modale.

const closeModal = () => {
  nonModalAreas.forEach((element) => {
    element.inert = false
  })
  // ici, le code ajouté précédemment
}

Voici le résultat :

voirTest modalede smashingmag dansCodePen

Supposons que vous ne vous sentiez pas à l'aise avec l'utilisation de l'attribut inert pour le moment et que vous souhaitiez créer un piège à focus manuellement, comme celui de A11y Solutions. Que pouvez-vous faire pour vous assurer que les utilisateurs de lecteurs d'écran ne puissent pas sortir de la modale ? aria-modal peut vous aider, mais n'oubliez pas que la prise en charge de cette propriété est assez fragile, notamment pour Talkback et VoiceOver pour iOS. La prochaine meilleure chose à faire est donc d'ajouter l'attribut aria-hidden="true" à tous les éléments qui ne sont pas la modale. Il s'agit d'un processus très similaire à celui que nous avons suivi pour l'attribut inert, et vous pouvez également utiliser les mêmes éléments dans le tableau que nous avons utilisé pour cette rubrique !

const openModal = () => {
  // ici, le code ajouté précédemment
  nonModalAreas.forEach((element) => {
    element.setAttribute('aria-hidden', 'true')
  })
}
const closeModal = () => {
  nonModalAreas.forEach((element) => {
    element.removeAttribute('aria-hidden')
  })
  // ici, le code ajouté précédemment
}

Ainsi, que vous décidiez d'utiliser l'attribut inert ou de créer manuellement un piège à focus, vous pouvez vous assurer que l'expérience utilisateur pour les utilisateurs de claviers et de lecteurs d'écran fonctionne au mieux.

Élément dialog

Vous avez peut-être remarqué le balisage que j'ai utilisé et que je n'ai pas utilisé le relativement nouvel élément <dialog>, et il y a une raison à cela. Oui, cet élément aide beaucoup en gérant le focus sur la modale et sur le bouton qui l'a ouverte facilement, mais, comme Scott O'Hara le souligne dans son article "Avoir un dialogue ouvert", il présente encore quelques problèmes d'accessibilité qui, même avec un polyfill, ne sont pas encore totalement résolus. J'ai donc décidé d'utiliser une approche plus robuste avec le balisage.

Si vous n'avez pas entendu parler de cet élément, il dispose de quelques fonctions pour ouvrir et fermer le dialogue, ainsi que de quelques nouvelles fonctionnalités qui seront pratiques lorsque nous créerons des modales. Si vous voulez vérifier comment il fonctionne, vous pouvez consulter la vidéo de Kevin Powell sur cet élément.

Cela ne veut pas dire que vous ne devez pas l'utiliser du tout. La situation de l'accessibilité concernant cet élément s'améliore, mais gardez à l'esprit que vous devez toujours prendre en considération certains détails pour vous assurer qu'il fonctionne correctement.

Autres modèles de composants

Je pourrais continuer avec de nombreux modèles de composants, mais pour être honnête, je pense que cela va devenir redondant car, en fait, ces modèles sont assez similaires entre les différents types de composants que vous pouvez faire. À moins que vous ne deviez fabriquer quelque chose de très peu conventionnel, les modèles que nous avons vus ici devraient suffire !

Ceci étant dit, comment pouvez-vous savoir ce que requerra un composant ? La réponse comporte de nombreuses nuances que cet article ne peut couvrir. Il existe certaines ressources comme le référentiel de composants accessibles de Scott O'Hara ou le système de design du gouvernement britannique, mais c'est une question qui n'a pas de réponse simple. La chose la plus importante à ce sujet est de toujours les tester avec des utilisateurs handicapés pour connaître les défauts qu'ils peuvent avoir en termes d'accessibilité.

Récapitulons

L'accessibilité du clavier peut être assez difficile, mais c'est réalisable une fois que vous comprenez comment les utilisateurs de clavier interagissent avec un site et quels principes vous devez garder à l'esprit. La plupart du temps, HTML et CSS font un excellent travail pour assurer l'accessibilité du clavier, mais parfois vous aurez besoin de JavaScript pour des modèles plus complexes.

C'est assez impressionnant tout ce qu'on peut faire pour l'accessibilité du clavier une fois qu'on a compris que la plupart du temps, le travail est fait avec les mêmes outils de base. Vous pouvez alors mélanger ces outils pour créer une expérience utilisateur formidable pour les utilisateurs de clavier !

La propriété align-self est une sous-propriété du module Flexible Box Layout. Elle permet de remplacer la valeur align-items pour des éléments flex spécifiques.

La propriété align-self accepte les 5 mêmes valeurs que la propriété align-items.

Syntaxe

align-self: auto | flex-start | flex-end | center | baseline | stretch
  .flex-item {
  align-self: flex-end;
}

Démo

voiralign-self demode css-tricks dansCodePen

Pardonnez le titre quelque peu putaclic... "jamais" est un mot fort, mais il s'agit d'un sujet important et mal compris.

Il circule un certain nombre d'idées fausses dans la sphère du développement Web, qui persistent alors même qu'elles sont régulièrement démenties. "Les liens externes doivent toujours s'ouvrir dans de nouveaux onglets" en est un bon exemple. CSS Tricks en a parlé en détail il y a près de dix ans (tl;dr : la plupart du temps faux), mais cette idée semble encore persister dans certains coins.

Exemple concret : l'idée qu'il n'y a pas de différence fonctionnelle entre les unités px, et em ou rem en CSS. C'est une idée fausse que j'entends encore et encore, alors je me suis dit que j'allais l'aborder ici, dans un billet.

Soyons clairs : l'unité que vous utilisez dans votre CSS est absolument importante. Et vous devez éviter les px lorsque vous définissez la taille de la police, dans la mesure du possible.

Encore une fois : "toujours" est un mot fort, et un peu dogmatique. Mais la vérité est la suivante : si vous choisissez la mauvaise unité, vous risquez d'écraser les préférences de vos utilisateurs, de leur rendre l'utilisation de votre site Web plus difficile (voire impossible) et de nuire au design par des effets secondaires visuels involontaires.

De quelles unités parlons-nous et que font-elles?

Avant d'aborder les raisons pour lesquelles nous devrions éviter d'utiliser px pour la taille de la police, assurons-nous que nous avons bien compris de quelles unités il s'agit et comment elles se comportent en général.

px

px est l'abréviation de pixel... bien qu'il ne s'agisse plus littéralement d'un pixel la plupart du temps. Il l'était autrefois, à l'époque où les écrans avaient tendance à avoir un ratio de pixels assez prévisible et de faible résolution, comme 1024×768. À cette époque, 1px était généralement égal à un pixel réel sur l'écran physique.

Les écrans affichent les images à l'aide d'une grille de lumières colorées appelées pixels. Un pixel est une lumière colorée sur l'écran ; le plus petit "point" possible que le matériel est capable de restituer. C'est ce que j'entends par pixel "littéral", "réel" ou "périphérique" dans cette section ; un pixel dans le monde physique.

Cependant, lorsque les écrans haute résolution (parfois appelés "rétina") sont apparus et que les appareils ont commencé à contenir plus de pixels dans moins d'espace, ces pixels physiques sont devenus super petits. En naviguant sur le Web sur un écran haute résolution, il aurait été extrêmement difficile de lire quoi que ce soit si 1px en CSS correspondait encore à un pixel de périphérique littéral, car les pixels eux-mêmes se sont rapidement réduits. Les smartphones modernes ont des résolutions encore plus élevées que les téléviseurs HD, après tout.

Au lieu de cela, les navigateurs sur les écrans haute résolution mettent à l'échelle ce qu'ils affichent (zoom avant, plus ou moins), afin que les pages Web ne soient pas illisibles. Les images et autres éléments peuvent toujours être affichés dans toute leur gloire haute résolution, mais le texte et les autres éléments sont mis à l'échelle pour maintenir la lisibilité.

Ainsi, de nos jours, 1px correspond généralement à la taille d'un pixel agrandi, "zoomé", plutôt qu'à un pixel littéral sur le matériel réel. Un élément de 1px dans notre CSS occupera probablement plusieurs pixels physiques du matériel, et nous n'avons pas vraiment de moyen dans le CSS pur de spécifier un pixel littéral du périphérique. Mais ce n'est pas grave, car ils sont généralement trop petits pour que nous ayons envie de nous en occuper.

Un exemple : les pixels de l'iPhone 14 Pro sont si microscopiques que 16px, en pixels de périphérique littéral, correspondraient à la taille d'une police d'écriture imprimée de `2pt`. Heureusement que les navigateurs les mettent à l'échelle pour nous !

La plupart de ces éléments ne sont pas vraiment importants dans le contexte de cette discussion, mais je pense qu'il est bon de les connaître quand même. La partie importante est la suivante : 1px est égal à ce que le navigateur traite comme un pixel unique (même si ce n'est pas littéralement un pixel sur l'écran matériel).

em et rem

Cela nous amène à em et rem, qui sont similaires l'un à l'autre. Pour continuer avec les anecdotes non strictement pertinentes mais néanmoins intéressantes : "em" est un terme typographique qui précède les ordinateurs de plusieurs décennies. Typographiquement, un em est égal à la taille courante de la police (NdT : c'est à dire relatif à la taille de police de son élément parent).

Si la taille de votre police est réglée sur 32 pt ("pt" signifie point, un autre terme typographique ancien encore parfois utilisé), alors 1em correspond à 32 pt. Si la taille actuelle de la police est de 20px, alors 1em = 20px (mais encore une fois : vous ne devriez pas définir les tailles de police en pixels — ceci est juste pour l'exemple).

Sur le Web, la taille de police par défaut est de 16px. Certains utilisateurs ne changent jamais cette valeur par défaut, mais beaucoup le font. Mais par défaut, au moins, 1em et 1rem seront tous deux égaux à 16px.

À l'origine, Em faisait référence à la largeur d'un caractère "M", d'où son nom. Mais il fait désormais référence à la taille actuelle de la police, plutôt qu'aux dimensions d'un glyphe spécifique.

La différence entre em et rem

Pour différencier les deux : 1rem est toujours égal à la taille de la police du navigateur — ou, plus précisément, à la taille de la police de l'élément html. rem signifie "root em", et la racine d'une page Web est la balise <html>. Donc, 1rem = la taille de la police du document, quelle qu'elle soit. (Qui, encore une fois, par défaut, est de 16px, mais peut être modifiée par l'utilisateur).

em, on l'a vu, est la taille de la police de l'élément courant. Prenez le CSS suivant :

.container {
  font-size: 200%;
}
p {
  font-size: 1em;
}

Avec le CSS ci-dessus, les paragraphes à l'intérieur de l'élément .container seraient deux fois plus grands. En effet, 1em signifie "la taille actuelle de la police", et à l'intérieur de l'élément .container, cette taille est de 200 %. 1em × 200% = 2em (32px par défaut).

Toutefois, les paragraphes situés à l'extérieur de l'élément .container conservent la taille de police normale de 1em (16px par défaut).

Si nous remplaçons em par rem dans le CSS ci-dessus, toutes les balises de paragraphe auront toujours la taille de police par défaut du navigateur, où qu'elles se trouvent.

`font-size : 1em` est équivalent à `font-size : 100%`.

Les unités `em` et `%` ne sont pas toujours équivalentes dans d'autres contextes. Par exemple, `width : 1em` et `width : 100%` seraient très probablement bien différents, puisque dans ce cas, le pourcentage est basé sur la largeur du conteneur parent, et non sur sa taille de police. Mais `%` et `em` sont identiques en ce qui concerne la propriété font-size.

Donc, pour résumer :

• 1em est la taille de la police de l'élément actuel
• 1rem (root em) est la taille de la police du document (c'est-à-dire celle du navigateur)

Très bien ; voilà ce que signifient les unités et d'où elles viennent. Répondons maintenant à la question de savoir pourquoi il est important de savoir laquelle nous utilisons.

Pourquoi tout cela est important

Une fois encore, l'idée fausse la plus répandue est la suivante : puisque 1em est de toute façon égal à 16px, l'unité choisie n'a pas d'importance. Et cela semble logique ; si 16px = 1rem, alors pourquoi la façon dont vous choisissez de le taper aurait-elle de l'importance ?

Rappelez-vous, em et rem sont relatifs ; par défaut, ils sont tous deux (en fin de compte) basés sur la taille de la police du navigateur.

En revanche, px ne l'est pas ; il s'agit d'une valeur statique qui n'est pas basée sur ou affectée par quoi que ce soit d'autre.

2rem correspond au double de la taille de la police du navigateur ; 0.5rem correspond à la moitié de celle-ci, et ainsi de suite. Ainsi, si l'utilisateur modifie sa taille de police préférée (NdT : p.ex. en modifiant les réglages de son navigateur), si vous avez utilisé em et rem, tout le texte de votre site Web sera modifié en conséquence, comme il se doit. 2rem est toujours le double de cette taille de police ; 0.5rem est toujours la moitié de celle-ci.

En revanche, les valeurs px sont statiques. 20px reste 20px, quelle que soit la taille de la police du conteneur, du navigateur ou de l'utilisateur. Quelle que soit la taille de la police préférée de l'utilisateur, lorsque vous définissez une valeur en pixels statiques, elle écrase ce choix et le remplace par la valeur exacte que vous avez spécifiée.

Cela signifie que si votre feuille de style utilise px pour définir la taille de la police, il sera impossible pour l'utilisateur de modifier tout texte basé sur cette valeur.

em et rem fonctionnent avec la taille de police de l'utilisateur ; px la remplace complètement.

C'est une très mauvaise chose. C'est inaccessible, et cela peut même empêcher quelqu'un d'utiliser le site tout court.

Ainsi, bien que ce comportement puisse être utilisé dans certains cas valables, ce n'est certainement pas ce que vous voulez comme valeur par défaut.

C'est également une très bonne raison d'éviter les unités de visualisation, comme `vw` ou `vh`, lors de la définition de la taille de la police. Ces unités sont également statiques et impossibles à modifier par l'utilisateur.

Tout au plus, une valeur comme `calc(1rem + 1vw)` pourrait être acceptable, car elle contient toujours `rem` comme base. Mais même dans ce cas, je vous recommande d'utiliser `clamp()` ou `media queries` pour définir les valeurs minimales et maximales, car les tailles d'écran vont souvent bien au-delà de ce que nous pouvons attendre ou tester.

Différences au-delà de la taille de la police

Ok, parlons maintenant de la façon dont px et em/rem varient même lorsque nous ne traitons pas spécifiquement de la propriété font-size.

Les développeurs testent généralement en effectuant un zoom avant ou arrière sur la page, et je pense que c'est de là que vient l'idée fausse au cœur de ce billet. Lorsque vous effectuez un zoom, tout est redimensionné (ou réduit) et, dans ce scénario, le choix de px ou de em/rem comme unité CSS n'a généralement pas d'importance. Les deux se comportent de la même manière, en ce qui concerne le zoom. Et la plupart des développeurs privilégiés ayant une bonne vue ne se rendront probablement pas compte qu'il y a plus que cela. Cependant, la chose délicate est la suivante :

Même au-delà de la taille de la police, px ne se comporte pas de la même manière que em et rem.

Les unités px sont toujours liées à la valeur mise à l'échelle des pixels sur l'écran. em et rem, en revanche, sont liés à la taille de la police du document, et non au zoom ou à l'échelle de la page.

Pour le démontrer, jetez un coup d'œil à ce CodePen :

voirDemonstrating px, em and remde collinsworth dansCodePen

Nous avons quelques paragraphes, chacun avec une bordure de 2px en bas, et une marge de 20px entre eux. Remarquez que nous utilisons des unités px pour les deux.

Si vous effectuez un zoom avant ou arrière, la taille et la distance des éléments restent relatives. En d'autres termes, plus vous effectuez un zoom avant, plus la ligne devient épaisse et plus l'espace entre les paragraphes est grand.

Pour vous épargner la peine, voici une capture d'écran, montrant ce même codepen avec un zoom de 400%. Le texte, la ligne et l'espacement sont tous 4 fois plus grands ; ils restent de la même taille les uns par rapport aux autres :

Lorsqu'il s'agit de faire un zoom avant ou arrière, il n'y a pas de réelle différence entre px et em ou rem. Mais le zoom n'est pas le seul moyen pour les utilisateurs de rendre les sites Web plus utilisables.

Comme mentionné précédemment, les utilisateurs peuvent également spécifier une taille de police par défaut et/ou minimale. Et lorsqu'ils le font, c'est là que la fonctionnalité commence à diverger.

Dans la capture d'écran ci-dessous, j'ai défini la taille de police par défaut de Firefox à 64px. Voilà ce que ça donne :

Comparez le texte de cette capture d'écran avec le texte de celle qui la précède. Remarquez comment, cette fois, les lignes ne sont pas plus épaisses, et les marges entre les paragraphes n'ont pas augmenté proportionnellement. Seul le texte lui-même est plus grand. Comme la largeur de la bordure et la marge ont toutes deux été définies en px, elles restent telles quelles et ne sont pas mises à l'échelle.

Vous remarquerez toutefois que si vous remplacez les px dans le CSS par les valeurs rem équivalentes, les lignes et les marges s'agrandissent !

Tout cela signifie que le choix de px plutôt que em et rem, ou l'inverse, répond à des motivations de design.

Donc, pour résumer,

• les valeurs px n'augmentent ni ne diminuent pas lorsque l'utilisateur modifie la taille de sa police de caractères,
• Les valeurs em et rem s'ajustent proportionnellement à la taille de la police.

Si vous souhaitez une démonstration interactive qui relie tout cela, consultez ce CodePen final ; ajustez le curseur en haut pour voir l'effet de la modification de la taille de la police du document sur divers éléments, en fonction de l'unité CSS qu'ils utilisent.

voirThe difference between px and rem in font scalingde collinsworth dansCodePen

Lequel choisir ?

Donc, sachant que les valeurs em et rem s'échelonnent en fonction de la taille de la police, mais pas les valeurs px, où cela nous mène-t-il ? Devrions-nous simplement ne jamais utiliser les px pour quoi que ce soit ?

Même si je pense que vous pouvez suivre cette voie si vous le souhaitez, je pense qu'il y a une place pour les valeurs px.

Puisque nous savons que les valeurs px ne changeront pas lorsque et si l'utilisateur ajuste sa taille de police, cela signifie que les unités de pixels sont en fait un excellent choix pour certains éléments esthétiques. Peut-être avons-nous un certain espacement que nous ne voudrions pas voir s'agrandir lorsque la taille de la police est plus grande. (S'il s'agit d'un grand bloc d'espace négatif par défaut, il ne serait peut-être pas judicieux de lui permettre de passer à une taille encore plus massive).

Peut-être y a-t-il des tailles de bordure que nous ne voudrions pas modifier, ou peut-être y a-t-il des éléments décoratifs sur la page, créés avec CSS, qui ne sembleraient pas bien fonctionner à une taille plus grande, juste parce que la police est plus grande. Peut-être ne voulons-nous pas que le remplissage augmente avec la taille de la police. px reste un bon choix dans tous ces cas.

Personnellement, je recommande de définir toutes les tailles en utilisant rem. Je n'utilise em que lorsque je veux que quelque chose soit proportionnel à la taille courante de la police (par exemple, une icône à côté d'un texte qui doit avoir exactement la même hauteur que les caractères, et un demi-caractère sur le côté). Je n'utiliserais pas px n'importe où, sauf pour les éléments de design que je ne voulais pas explicitement mettre à l'échelle avec la taille de la police.

Mais une fois de plus, si vous retenez quelque chose de ce billet :

Ne définissez jamais la taille de la police en unités px — du moins, pas à moins d'être absolument sûr de ce que vous faites, de son comportement et de son accessibilité.

Une note importante sur les media queries

Il s'agit d'un addendum tardif à cet article, mais il est important d'éviter les px dans les requêtes media (media queries) pour les mêmes raisons que celles évoquées ci-dessus ; cela fonctionnera bien lorsque l'utilisateur zoome, mais une requête media qui utilise les px échouera lorsque les utilisateurs définiront eux-mêmes une taille de police plus grande.

@media (min-width: 800px) {
  /* Modifier la taille de police n'affectera pas ce breakpoint */
}
@media (min-width: 50rem) {
  /* Modifier la taille de police affectera ce breakpoint */
}

En effet, lorsque la taille de la police augmente, 50rem devient une valeur différente en fonction de cette préférence, alors que 800px ne le devient pas.

La plupart du temps, lorsque nous écrivons du CSS pour des points de rupture (breakpoints) plus grands, nous partons du principe qu'il y a suffisamment de surface d'écran pour que les éléments puissent s'étendre. Cela peut ne pas être le cas si l'utilisateur a défini une très grande taille de police, et le fait de définir nos requêtes média en rem plutôt qu'en px nous permet d'éviter cette hypothèse et de répondre aux préférences de l'utilisateur.

J'ai rencontré ce problème sur mon site ; je définissais tous mes points de rupture en px. Cependant, lorsque j'ai augmenté la taille de la police par défaut, mes requêtes média n'ont pas répondu, car elles ne tenaient compte que de la largeur en pixels de l'écran. J'avais donc toujours une minuscule barre latérale, avec un texte énorme écrasé de façon illisible à l'intérieur, puisque je n'avais pas tenu compte des préférences des utilisateurs. J'ai changé pour rem immédiatement après, et cela a résolu le problème.

En résumé, évitez d'utiliser px dans les requêtes média, sauf si vous êtes sûr de savoir ce que vous faites et quel effet cela aura sur les utilisateurs qui définissent leur propre taille de police dans le navigateur.

Un dernier mot sur l'accessibilité

Les directives d'accessibilité stipulent généralement que les applications Web doivent être utilisables jusqu'à 200 % de zoom et/ou de taille de police. Vous remarquerez que les démos ci-dessus vont bien au-delà.

C'est en partie pour le contraste, mais il est important de noter que de nombreux utilisateurs iront bien au-delà également, en fonction de leurs besoins et de leurs préférences. Une personne ayant une mauvaise vue ne s'arrêtera pas simplement à 200 % si cela ne lui convient pas. Nous devrions faire de notre mieux pour les inclure, en construisant nos sites et nos applications pour qu'ils soient lisibles et utilisables quoi qu'il arrive.

J'ai entendu certains spécialistes de la technologie affirmer que leurs utilisateurs sont jeunes et/ou férus de technologie, et que les personnes qui ont besoin d'une grande taille de police ne font pas partie de leur public et ne doivent donc pas être prises en compte. Mais j'aimerais insister sur le fait que c'est faux, présomptueux, et franchement, handicapant.

16px est juste une valeur par défaut. Ce n'est pas une norme, ce n'est pas une cible, et ça ne devrait pas être une supposition. Même en mettant de côté l'âgisme inhérent à cet argument, les besoins varient même chez les jeunes. L'invalidité n'a pas de seuil d'âge. Je connais personnellement une personne d'une trentaine d'années, employée comme développeur à plein temps (c'est-à-dire très jeune et très douée pour la technologie), qui doit définir une taille de police minimale nettement supérieure à la valeur par défaut à cause de sa vision. Les sites Web et les applications sont régulièrement cassés pour eux, parfois au point d'être inutilisables, parce que les développeurs ne tiennent pas compte de leurs besoins.

Je rappelle tout cela pour souligner l'importance de tester les UI comme le feraient nos utilisateurs. Ci-dessus, j'ai utilisé 64px, et il est vrai que cela semble être une sélection assez extrême, étant quatre fois plus grande que la valeur par défaut... mais encore une fois, et si ce n'était pas le cas ? Et si un utilisateur en avait vraiment besoin ? Dire, de fait, à un utilisateur "tu as besoin de trop" n'est pas quelque chose que nous souhaitons faire.

Il y aura toujours des limites pratiques à ce que nous pouvons accommoder, bien sûr. Mais quoi qu'il en soit, nous devrions au moins aller aussi loin que possible. Même si le taux de 4 fois n'est pas toujours réalisable, il existe de nombreuses options possibles entre 100 et 400 % que les utilisateurs pourraient choisir de manière réaliste et sur lesquelles ils pourraient compter, et nous devrions faire de notre mieux pour ne pas les gêner. À défaut, ce que nous construisons sur le Web devrait au moins être suffisamment flexible pour aller bien au-delà des valeurs par défaut.

16px n'est qu'un défaut. Ce n'est pas une norme, ce n'est pas un objectif, et cela ne devrait pas être une hypothèse. Nous pouvons, et devons, faire mieux.

NdT : voir également l'excellent article de Josh Comeau (en anglais) sur le même sujet.

L'accessibilité du clavier est un élément important de l'expérience utilisateur. Les directives d'accessibilité aux contenus Web (WCAG) contiennent de nombreux critères à ce sujet. Pourtant, il est quelque peu négligé, ce qui affecte l'expérience de nombreux utilisateurs, principalement les personnes souffrant de handicaps moteurs — toute condition qui limite les mouvements ou la coordination.

Certaines conditions telles qu'un bras cassé, la perte ou l'endommagement d'un membre, la dystrophie musculaire, l'arthrite et d'autres peuvent rendre impossible l'utilisation d'une souris pour naviguer sur un site. Par conséquent, rendre un site navigable au moyen du clavier est un élément très important pour garantir l'accessibilité et la convivialité de nos sites Web.

L'importance de rendre un site accessible aux utilisateurs souffrant de handicaps moteurs devient encore plus évidente lorsque vous apprenez qu'ils ont accès à davantage d'options technologiques d'assistance. Les claviers ne sont même pas le point central de l'assistance aux handicapés moteurs ! Il existe des outils comme les commutateurs que vous utilisez avec votre main (ou même avec votre tête) pour travailler avec n'importe quel appareil, ce qui aide beaucoup les personnes souffrant de handicaps moteurs plus graves. Vous pouvez voir comment ces technologies fonctionnent dans cette démonstration faite par Rob Dodson ou dans cette vidéo de Christopher Hills.

Dans cet article, je vais vous expliquer comment utiliser HTML et CSS pour créer une expérience accessible pour les utilisateurs de claviers, et je listerai les critères WCAG que nous devons prendre en considération.

HTML

L'une des bases de la création d'un site Web accessible pour les utilisateurs de clavier est de savoir quels éléments doivent être navigables au clavier. Pour cela, une bonne sémantique HTML est cruciale car elle indiquera le type d'éléments sur lesquels nous voulons nous concentrer avec la navigation au clavier.

Les bases

Lorsqu'un utilisateur appuie sur la touche Tab, il peut sélectionner l'élément suivant dans le code HTML, et lorsqu'il appuie sur les touches Shift + Tab, il peut accéder au dernier élément. Ceci étant dit, quels éléments doivent être focalisables ? Réponse : tout ce qui nécessite une interaction avec l'utilisateur ! Vous devez pouvoir trouver, entre autres, les éléments button, a, input, summary, textarea, select, et les contrôles des éléments audio, et video (lorsque vous leur ajoutez l'attribut controls). En outre, certains attributs peuvent rendre un élément navigable au clavier, comme contenteditable ou tabindex. Dans le cas de Firefox, toute zone comportant un défilement sera également accessible au clavier.

En plus de cela, vous devez pouvoir :

• Activer les éléments `button`, `select`, `summary` et `a` à l'aide de la touche `Entrée`. N'oubliez pas qu'à l'exception de l'élément `a`, vous pouvez également les activer avec la touche `Espace`.
• Utiliser les touches fléchées pour naviguer entre les différentes `input` avec le type `radio` si elles partagent le même attribut `name`.
• Cocher ces entrées à l'aide de la touche `Espace` (n'oubliez pas que lorsque vous naviguez avec les touches flèches, les `input` radio sont cochés dès que le clavier est activé, mais que cela ne se produit pas avec les `input` de type case à cocher).
• Utiliser les touches flèche-vers-le-haut et flèche-vers-le-bas pour naviguer entre les différentes options d'un élément `select`.
• Ferme la liste affichée de l'élément `select` et les diverses fenêtres contextuelles d'`input`.
• Utiliser les touches flèches pour faire défiler verticalement ou horizontalement un document.

Il existe probablement d'autres interactions, dont certaines dépendent des différences entre les systèmes d'exploitation et les navigateurs, mais ce que nous avons vu couvre l'essentiel de ce que vous pouvez faire avec le clavier.

Cela signifie-t-il que ces éléments sont automatiquement accessibles au clavier par défaut ? Pas tout à fait. Une bonne structure HTML est très utile, elle rend l'essentiel du contenu accessible par défaut, mais vous devez quand même couvrir certains problèmes.

Par exemple, certains types d'input comme date, datetime-local, week, time et month ont des popups qui peuvent fonctionner différemment selon les navigateurs. Chrome, par exemple, vous permet d'ouvrir le popup du sélecteur de date (date picker) en appuyant sur la touche Entrée ou Espace dans un bouton dédié dans la saisie. Cependant, avec Firefox, vous devez appuyer sur la touche Entrée (ou Espace) dans les champs du jour, du mois ou de l'année pour ouvrir la fenêtre contextuelle et modifier chaque champ à partir de là.

Ce manque de cohérence peut être un peu rebutant, et c'est peut-être juste une question de préférence personnelle. Toujours est-il que j'ai l'impression que l'expérience Firefox n'est pas très intuitive, ce qui amène à penser que, sans doute, l'une de ces expériences est plus accessible au clavier que l'autre. Donc, si vous voulez créer une bonne expérience clavier, accessible et cohérente entre les navigateurs, il vous faudra plus que du HTML pour cela. Si vous voulez essayer vous-même, consultez cette compilation (en français) de types d'entrée par MDN et naviguez par vous-même.

En plus du point précédent, certains composants exigent que les éléments soient focalisables au clavier sans être nativement sélectionnables. Dans d'autres cas, nous devons gérer le focus clavier manuellement, et notre balisage doit nous aider à le faire. Dans les deux cas, nous devrons utiliser un attribut HTML qui nous aidera dans cette tâche.

Attribut tabindex

Cet attribut nous aidera à amener l'accessibilité clavier à des niveaux de configuration plus fins. Il prend un nombre entier, et son utilisation correcte nous aidera à rendre un élément DOM accessible au clavier. Avec tabindex, nous pouvons trouver trois cas différents :

tabindex="0"

Il fait en sorte que l'élément soit focalisable par le clavier. En général, vous ne souhaitez pas ajouter le focus clavier à un élément, sauf s'il n'est pas interactif, mais certains scénarios l'exigent.

L'un d'eux est lorsque vous avez un composant avec un défilement à côté de l'élément body. Sinon, les utilisateurs du clavier ne pourront pas voir le contenu dans toute son étendue. Parmi les composants susceptibles d'avoir ce problème, citons les carrousels avec défilement, les tables et les extraits de code. Pour donner un exemple, tout extrait de code créé à l'aide de prism.js possède l'attribut tabindex="0". Ouvrez le site de prism.js et naviguez-y à l'aide de la touche Tab. Vous pourrez avoir un focus sur les snippets et contrôler le défilement vertical et horizontal à l'aide des touches flèches.

Certaines personnes qui s'initient à l'accessibilité du Web pensent que c'est une bonne idée d'ajouter l'attribut tabindex="0" à chaque élément car elles pensent que cela aidera les utilisateurs de lecteurs d'écran à naviguer facilement sur un site. Il s'agit d'une pratique terrible pour deux raisons :

1. Les utilisateurs de lecteurs d'écran ont plusieurs façons de naviguer sur un site. Ils peuvent sauter entre les titres, les balises de repère (telles que main, nav, ou aside) ou les éléments de formulaire, et ils n'ont pas besoin de cette aide supplémentaire pour créer un site accessible, tant que le balisage est approprié.
2. Cela peut rendre la navigation au clavier difficile car un utilisateur devra appuyer plusieurs fois sur la touche Tab pour arriver au contenu souhaité, et pour certains handicaps moteurs, le fait d'avoir trop d'éléments focalisables peut créer une expérience physiquement pénible.

Donc, pour résumer : c'est une technique utile pour certains éléments, mais la plupart du temps, vous vous en sortirez très bien si vous ne l'utilisez pas, et en tout cas, vous ne devez pas l'utiliser dans chaque élément de votre site.

Tabindex négatif

Avant de commencer, nous devons garder à l'esprit deux concepts : un élément DOM est à la fois focalisable (c'est-à-dire que vous pouvez le focaliser de manière programmatique avec JavaScript) et tabulable (c'est-à-dire qu'il peut être sélectionné avec la touche Tab).

En gardant cela à l'esprit, c'est ici que le tabindex négatif entre en jeu car il le retire de l'arbre d'accessibilité, il ne peut plus être tabulé, (mais vous pouvez toujours le focaliser avec JavaScript). C'est important pour des composants spécifiques car, dans certains cas, nous devons faire en sorte qu'un élément normalement tabulable ne puisse pas être tabulé, ou qu'un élément soit focalisable mais pas tabulable.

Les onglets en sont un exemple. Un modèle recommandé pour ce composant est de s'assurer que lorsque vous appuyez sur la touche Tab quand vous êtes situé sur l'onglet actif, cela nous amène au tabpanel actif plutôt que mettre le focus sur l'onglet suivant. Nous pouvons y parvenir en ajoutant un tabindex négatif à tous les onglets non actifs comme ceci :

<ul role="tablist">
  <li role="presentation">
    <button role="tab" href="#panel1" id="tab1" aria-selected="true">
      Tab one
    </button>
  </li>
  <li role="presentation">
    <button role="tab" href="#panel2" id="tab2" tabindex="-1">
      Tab two
    </button>
  </li>
  <li role="presentation">
    <button role="tab" href="#panel3" id="tab3" tabindex="-1">
      Tab three
    </button>
  </li>
  <li role="presentation">
    <button role="tab" href="#panel4" id="tab4" tabindex="-1">
      Tab four
    </button>
  </li>
</ul>

Nous verrons plus tard d'autres exemples sur la façon dont un tabindex négatif nous aidera à avoir plus de contrôle sur la gestion de l'état du focus dans différents composants, mais gardez à l'esprit qu'un tabindex négatif sera important dans ces cas.

Enfin, vous pouvez mettre n'importe quel nombre entier négatif dans la propriété tabindex, et cela fonctionnera de la même manière. tabindex="-1" et tabindex="-1000" ne feront aucune différence, mais par convention, j'ai tendance à utiliser -1 lorsque nous utilisons cet attribut.

Tabindex positif

Un tabindex positif rendra l'élément focalisable par le clavier, mais l'ordre sera défini en fonction de l'entier utilisé. Cela signifie que le clavier parcourra d'abord tous les éléments avec l'attribut tabindex="1", puis ceux avec tabindex="2", et après avoir parcouru tous les éléments avec un tabindex positif, il prendra en compte tous les éléments interactifs par défaut et ceux avec l'attribut tabindex="0". C'est ce que l'on appelle le scope de navigation du focus ordonné par tabindex.

Maintenant, c'est une configuration que vous ne devriez pas utiliser. Il est préférable de placer les éléments focalisables requis dans votre site dans l'ordre nécessaire. Sinon, vous pourriez créer une expérience très déroutante pour les utilisateurs du clavier, ce qui constituerait un échec du critère 2.4.3 des WCAG : Ordre de focalisation.

Cela pourrait être utile si vous voulez que les utilisateurs du clavier se concentrent sur les widgets avant d'atteindre le contenu de la page, mais cela serait un peu déroutant pour les utilisateurs de technologies d'assistance (comme les lecteurs d'écran). Donc, encore une fois, vous feriez mieux de créer un ordre logique dans le DOM.

Attribut inerte

Je dois noter rapidement un attribut entrant qui nous aidera beaucoup avec l'accessibilité du clavier, appelé inert. Cet attribut rendra le contenu inaccessible par les technologies d'assistance.

Bon, vous vous demandez peut-être comment il peut être utile que quelque chose supprime l'accessibilité du clavier, mais dans certains cas, c'est une bonne chose ! Un composant qui en bénéficiera est celui des modales. En ajoutant cet attribut à tous les éléments du site, à l'exception de cette modale, il sera facile de créer un "piège à focus". Ainsi, vous vous assurerez que l'utilisateur ne peut pas naviguer accidentellement vers d'autres parties du site à l'aide de la touche Tab, à moins qu'il ne ferme cette modale. Pour l'instant, la création d'un piège à clavier nécessite une grosse réflexion avec JavaScript (je vous expliquerai comment dans la deuxième partie de ce guide). Donc, avoir un moyen de rendre la chose plus facile avec cet attribut sera bien pratique.

Ça paraît plutôt cool, non ? Eh bien, malheureusement, l'utilisation de cet attribut n'est pas encore recommandée. Si vous consultez la page de caniuse.com sur cet attribut, vous remarquerez qu'il est très récent ; Opera ne le prend pas encore en charge. L'implémentation la plus récente de cet attribut est la version 105 de Firefox, et au moment de la rédaction de cet article, il s'agit d'une version bêta ! Il est donc encore très tôt pour le faire. Il existe un polyfill pour l'attribut inert, mais pour l'instant, il est un peu coûteux en termes de performances. Je vous suggère donc sérieusement de ne pas l'utiliser maintenant pour la production. Mais une fois que nous aurons un support adéquat pour cet attribut, certains modèles de composants seront plus faciles à créer.

CSS

CSS est un outil essentiel pour l'accessibilité du clavier car il nous permet de créer un niveau de personnalisation de l'expérience, ce qui est important pour la conformité aux critères WCAG 2.2. De plus, CSS possède de multiples sélecteurs qui aideront à créer une bonne expérience clavier, mais attention car une mauvaise utilisation de certaines propriétés peut être contre-productive. Plongeons dans l'utilisation de CSS pour créer une expérience accessible aux utilisateurs de clavier.

Indicateur de focus

Lorsque vous utilisez une souris, vous pouvez voir avec quel élément vous pouvez interagir grâce au curseur, et vous ne voudriez pas retirer le curseur à votre utilisateur, n'est-ce pas ? Cela le rendrait incapable de savoir quel élément il veut utiliser !

Nous avons un concept similaire pour la navigation au clavier, et il s'appelle un indicateur de focus, qui par défaut est un contour qui entoure un élément focalisable par le clavier lorsqu'il est sélectionné par celui-ci. Il est essentiel de s'assurer que tous vos éléments accessibles au clavier disposent d'un indicateur de focus. C'est une condition importante pour rendre un site Web accessible au clavier, selon les critères WCAG :

Le style de focus est différent selon le navigateur que vous utilisez. Vous pouvez voir comment il se présente dans les différents navigateurs dans ces images par défaut et lorsque vous utilisez la propriété CSS color-scheme réglée sur dark, juste pour vérifier comment les styles par défaut se comporteraient en mode sombre.

Comme vous pouvez le remarquer, les navigateurs basés sur Chromium comme Chrome ou Edge ont un contour noir et blanc, qui fonctionne en mode clair et foncé. Firefox a opté pour un contour bleu qui se remarque dans les deux modes. Et Safari (et les navigateurs basés sur Webkit, car à l'heure actuelle, tous les navigateurs iOS utilisent Webkit comme moteur de navigation) a presque le même aspect que Firefox, mais avec un contour encore plus subtil pour un schéma de couleurs sombres.

Critère 2.4.11 des WCAG #.

Maintenant, les indicateurs de focus par défaut sont visibles, mais sont-ils suffisants ? La réponse est "non". Même si ça peut fonctionner dans certains cas, les personnes souffrant de déficiences visuelles auront du mal à le remarquer. Les WCAG ont donc créé le critère de réussite 2.4.11 - Apparence de focus pour rendre un indicateur de focus accessible. Pour l'instant, ce critère fait partie des WCAG 2.2, qui sont une recommandation candidate. Il est donc peu probable qu'il soit modifié avant la version finale, mais gardez à l'esprit qu'il est toujours susceptible d'être modifié.

Il y a quelque chose d'important à considérer ici, et c'est la zone de l'indicateur de focus. Cette zone doit répondre aux exigences de contraste de ce critère. Pour illustrer cela, je vais utiliser un exemple que Sara Soueidan a réalisé pour son article "A guide to designing accessible, WCAG-compliant focus indicators".

Cet exemple utilise un contour, mais n'oubliez pas que vous pouvez utiliser d'autres propriétés pour déterminer l'état du focus, comme la couleur d'arrière-plan ou des façons créatives d'utiliser le box-shadow, tant que cela est conforme aux exigences. En tout cas, n'utilisez pas la propriété outline : none pour éliminer le contour de l'élément.

C'est important pour le mode de contraste élevé de Windows, car lorsqu'il est actif, les couleurs de votre site Web seront remplacées par celles choisies par l'utilisateur. Ainsi, dépendre de propriétés telles que background-color n'aura aucun effet à ce niveau. À la place, utilisez la déclaration CSS outline-color : transparent avec l'épaisseur appropriée pour respecter les critères WCAG. Vous pouvez voir des exemples de ce fonctionnement dans mon article sur le mode de contraste élevé de Windows.

La taille optimale des contours

Une façon simple de créer un indicateur de focus conforme est d'utiliser cette méthode que Stephanie Eckles a suggérée dans sa conférence Modern CSS Upgrades To Improve Accessibility. Tout d'abord, nous définissons des propriétés personnalisées dans les éléments interactifs. N'oubliez pas que vous pouvez ajouter d'autres éléments à la règle en fonction de la complexité de votre projet :

/* Ajoutez d'autres selecteurs dans cette règle :is si nécessaire */
:is(a, button, input, textarea, summary) {
  --outline-size: max(2px, 0.08em);
  --outline-style: solid;
  --outline-color: currentColor;
}

Et ensuite, nous utilisons ces propriétés personnalisées pour ajouter une règle de focus global :

:is(a, button, input, textarea, summary):focus {
  contour: var(--outline-size) var(--outline-style) var(--outline-color);
  outline-offset: var(--outline-offset, var(--outline-size));
}

L'utilisation de 0,08em ici permet de donner une taille de contour plus grande si la police est plus grande, ce qui permet de mieux adapter la zone de contraste de l'élément à la taille de la police de l'élément.

Gardez à l'esprit que même si les WCAG mentionnent que la zone de mise au point "est au moins aussi grande que la zone d'un périmètre de 1 pixel CSS d'épaisseur de l'élément non mis au point", elles mentionnent également qu'elle doit avoir "un rapport de contraste d'au moins 3:1 par rapport aux couleurs adjacentes non indicatrices de mise au point, ou n'est pas plus fine que 2 pixels CSS". Ainsi, une épaisseur minimale de 2px est nécessaire pour se conformer aux WCAG.

N'oubliez pas que vous pouvez avoir besoin d'une ligne plus épaisse si vous utilisez un outline-offset négatif, car cela réduira le périmètre du contour. De même, l'utilisation d'un contour pointillé ou en pointillé réduira la zone ciblée de moitié environ, vous devrez donc utiliser une ligne plus épaisse pour compenser.

La zone idéale du contour est liée au périmètre de l'élément. Sara Soueidan a une fois de plus fait un excellent travail en expliquant le fonctionnement de cette formule dans son article sur les indicateurs de focus. Consultez-le si vous voulez mieux comprendre les mathématiques qui se cachent derrière cette question et comment les appliquer.

Sélecteur CSS liés au focus

En CSS, vous utilisez normalement la pseudo-classe :focus pour appliquer un style à un élément lorsqu'il est focalisé par une tabulation clavier, et elle fait bien son travail. Mais les CSS modernes nous ont donné deux nouvelles pseudo-classes, l'une qui nous aide dans un certain cas d'utilisation et l'autre qui résout un problème se produisant lorsque nous utilisons la pseudo-classe :focus. Ces pseudo-classes sont :focus-within et :focus-visible. Voyons ce qu'elles font et comment elles peuvent nous aider à améliorer l'accessibilité du clavier :

:focus-within

Cette pseudo-classe ajoute un style à chaque fois que l'élément est focalisé ou que l'un de ses enfants l'est également. Faisons un exemple rapide pour montrer à quoi cela ressemble :

<form>
  <label for="name">
    Name:
    <input id="name" type="text" />
  </label>
  <label for="email">
    Email:
    <input for="email" type="email" />
  </label>
  <button>Submit</button>
</form>

Note rapide au passage : il serait préférable de ne pas utiliser label pour envelopper l'élément d'input. Ça fonctionne dans tous les navigateurs, mais ça ne fonctionne pas bien avec le logiciel de reconnaissance vocale Dragon car il ne sera pas reconnu de manière correcte.

formulaire {
  display: grid;
  gap: 1em;
}
label {
  affichage: grille;
  gap: 1em;
  padding: 1em;
}
label:focus-within {
  background-color: rebeccapurple;
  couleur: blanc;
}

Cette pseudo-classe est intéressante pour enrichir les styles de certains composants, comme montré précédemment, et dans d'autres, elle aide beaucoup à rendre le contenu accessible aux utilisateurs du clavier. Par exemple, j'ai créé une carte pour mon article sur les media queries hover, pointer, any-hover et any-pointer. Cette carte affiche le contenu lorsque l'utilisateur place le curseur dessus, mais elle affiche également le contenu lorsque vous focalisez le bouton à l'intérieur de celle-ci à l'aide de la pseudo-classe :focus-within en utilisant les mêmes règles qui sont déclenchées au survol. Vous pouvez consulter le code dans l'article mentionné ainsi que dans ce CodePen :

voirKeyboard accessible animated cardde smashingmag dansCodePen

:focus-visible

D'autre part, nous avons un comportement assez intéressant avec les styles de focus, en raison de la façon dont le navigateur décide quand appliquer cet état à un élément. Si vous utilisez la pseudo-classe :focus, la plupart des navigateurs considéreront que cliquer sur l'élément revient à le focaliser, ce qui crée un "faux positif" où l'élément semble être focalisé par un clavier alors que ce n'est pas le cas.

Pour résoudre ce problème mineur, nous avons maintenant la pseudo-classe :focus-visible qui crée un état de focalisation si et seulement si l'élément est focalisé par un clavier. Gardez à l'esprit que ce comportement s'appliquera aux éléments comme button ou a et à la plupart des éléments d'input comme checkbox, radio ou submit. Mais les styles de focalisation seront toujours appliqués lorsque vous cliquez sur les éléments comme select, certains input qui reçoivent tout type de texte comme text, number, ou l'élément textarea.

Cela ne se produit plus aujourd'hui car les navigateurs modernes utilisent :focus-visible comme état de focalisation par défaut. Mais n'oubliez pas que vous souhaitez probablement modifier l'indicateur de focus par défaut du navigateur pour être conforme à la norme WCAG 2.4.11. Vous aurez donc besoin de :focus-visible pour éviter ce comportement.

Si vous consultez la page de caniuse.com sur la pseudo-classe :focus-visible, vous remarquerez qu'il est actif dans tous les navigateurs. Mais dans Safari, il est actif depuis une version relativement récente (15.4, qui a été publiée le 13 mars 2022), ce qui signifie que certains utilisateurs n'ont probablement pas encore mis à jour leur navigateur. Par conséquent, nous devrions offrir une sorte de solution de repli si le navigateur ne prend pas en charge cette pseudo-classe. Nous pouvons le faire en utilisant la feature query @supports.

Précédemment, nous avons créé un bon style global pour le style focus, appliquons maintenant la pseudo-classe :focus-visible à cette règle :

@supports selector(:focus-visible) {
  *:focus {
    outline: none;
  }
  *:focus-visible {
    outline: var(--outline-size) var(--outline-style) var(--outline-color);
    outline-offset: var(--outline-offset, var(--outline-size));
  }
}

Remarque rapide : je sais que j'ai indiqué que l'utilisation de la règle outline : none n'était pas une bonne idée, mais comme nous la remplaçons par :focus-visible, il s'agit d'un scénario "acceptable" pour l'utiliser. N'oubliez pas d'utiliser outline même s'il n'est pas visible. Outline est votre ami !

Considérations sur la mise en page

La puissance des CSS modernes pour créer des mises en page est formidable, mais il y a un ensemble de pratiques que nous devrions essayer d'utiliser avec prudence car elles peuvent rendre l'expérience de navigation au clavier problématique.

display : contents

Cette règle est très intéressante. Elle supprime la boîte de l'élément et fait que les enfants de l'élément agissent comme s'ils étaient des enfants directs de l'élément du grand-parent, sans supprimer la sémantique. Elle fait que les enfants d'un élément se comportent comme s'ils étaient ses frères et sœurs. Cela peut sembler un peu confus, je vais donc l'expliquer par un exemple. Supposons que nous ayons le balisage de l'en-tête de ce site :

<header>
  <a href="#">Go to home</a>
  <nav>
    <ul>
      <li>
        <a href="#">Clothes</a>
      </li>
      <li>
        <a href="#">Accessories</a>
      </li>
      <li>
        <a href="#">Shoes</a>
      </li>
    </ul>
  </nav>
</header>

Si nous ajoutions la règle display : contents à l'élément ul, nous supprimerions la boîte sans supprimer la sémantique, ce qui ferait des éléments li les enfants de l'élément parent de ul (dans ce cas, le conteneur nav) comme ceci :

<header>
  <a href="#">Go to home</a>
  <nav>
    <li><a href="#">Clothes</a></li>
    <li>
      <a href="#">Accessories</a>
    </li>
    <li>
      <a href="#">Shoes</a>
    </li>
  </nav>
</header>

Et encore, c'est sans supprimer la sémantique de l'élément parent. Cela apporte quelques possibilités intéressantes pour la création de mises en page, comme l'explique Kevin Powell dans sa vidéo sur cette propriété. Cependant, elle a un comportement avec les éléments interactifs du clavier qu'il faut éviter.

Si vous l'utilisez dans un élément pouvant être focalisé par le clavier, ces éléments ne pourront pas être tabulés. Pour être juste, il est très peu probable que vous vous trouviez dans une situation où vous devez utiliser display : contents dans un élément focalisable par le clavier (le seul cas auquel je puisse penser si vous voulez l'utiliser pour réinitialiser les styles de ces éléments). Et les problèmes d'accessibilité de cette propriété sont pour d'autres raisons plus courantes (Safari a un bug qui supprime la sémantique pour les éléments de type table et button dans la version 16), mais si vous vous trouvez d'une manière ou d'une autre dans cette situation, évitez-la à tout prix.

Propriété de commande de Grid et Flex

Grid et flexbox ont changé ce que nous pouvons faire avec la création de mises en page. Ce sont des outils incroyables qui nous aident à créer des mises en page aussi compliquées que nous le souhaitons, mais n'oubliez pas qu'ils peuvent créer des problèmes d'accessibilité.

Comme Manuel Matuzović l'a mentionné dans son exposé The Dark Side of the Grid, lorsque nous modifions l'ordre des éléments visuellement, soit en définissant un ordre explicite dans une grille avec des propriétés telles que grid-row et grid-column, soit en utilisant la propriété order sur flexbox ou grid, l'ordre d'apparition des éléments dans le DOM ne sera pas modifié.

Ce décalage entre l'ordre DOM et l'ordre visuel peut créer une expérience déroutante pour de nombreux utilisateurs, y compris les utilisateurs de clavier. Si nous modifions trop l'ordre visuel, cela peut créer une expérience déroutante pour eux, car la navigation au clavier pourrait ne pas fonctionner logiquement. Comme je l'ai mentionné dans la section sur le tabindex positif, le critère WCAG 2.4.3 - Ordre de focus, cette navigation au clavier doit préserver un ordre qui "préserve le sens et l'opérabilité."

Vérifions cela à l'aide d'un exemple. Jetons un coup d'œil à ce balisage, et ordonnons-les à l'aide d'une grille :

<ul role="list">
  <li><button>1</button></li>
  <li><button>2</button></li>
  <li><button>3</button></li>
  <li><button>4</button></li>
  <li><button>5</button></li>
  <li><button>6</button></li>
  <li><button>7</button></li>
  <li><button>8</button></li>
  <li><button>9</button></li>
</ul>

button:focus {
  outline: max(2px, 0.08em) solid currentColor;
  outline-offset: -7px;
}
@supports selector(:focus-visible) {
  button:focus {
    outline: none;
  }
  button:focus-visible {
    outline: max(2px, 0.08em) solid currentColor;
    outline-offset: -7px;
  }
}

Si vous utilisez la navigation au clavier, vous remarquerez que l'ordre est assez simple. Il se lit de gauche à droite et de haut en bas, et la navigation sera la même. Utilisons maintenant les propriétés de la grille pour effectuer quelques modifications :

ul
  li:where(:nth-child(1), :nth-child(5), :nth-child(7), :nth-child(9)) {
  grid-row: span 2;
  grid-column: span 2;
}
ul li:where(:nth-child(1), :nth-child(5)) {
  order: 2;
}
ul li:where(:nth-child(7), :nth-child(8)) {
  order: -1;
}
ul li:nth-child(4) {
  grid-row: 3;
  grid-column: 2 / span 2;
}
ul li:nth-child(3) {
  grid-row: 5 / span 3;
  grid-column: 3;
}

Maintenant, il a l'air complètement désorganisé. Bien sûr, la mise en page a l'air drôle, mais lorsque vous commencez à y naviguer avec la touche Tab, l'ordre est très aléatoire. Il y a un certain degré de prévisibilité maintenant parce que j'ai utilisé des chiffres comme étiquette du bouton, mais que se passe-t-il s'ils ont un contenu différent ? Il serait impossible de prédire quel sera le prochain bouton focalisé avec un clavier.

C'est le genre de scénario qu'il faut éviter. Cela ne signifie pas que vous ne pouvez pas ordonner explicitement un élément dans une grille ou utiliser la propriété order. Cela signifie que vous devez faire attention à la gestion de vos mises en page et vous assurer que l'ordre visuel et l'ordre du DOM correspondent autant que possible.

À propos, si vous voulez l'essayer par vous-même, vous pouvez voir la démo de ce code ici et expérimenter par vous-même cette navigation chaotique au clavier :

voirFocus order demode smashingmag dansCodePen

Quelques modèles de composants

Avec ce que nous avons vu sur HTML et CSS, nous pouvons créer quelques composants simples pour améliorer l'expérience des utilisateurs de clavier.

Accordéons

Nous pouvons créer des accordéons accessibles au clavier avec juste du HTML grâce aux éléments details et summary. Il dispose d'une navigation au clavier par défaut, et la prise en charge des lecteurs d'écran est assez bonne. Attention toutefois à certaines interactions entre les lecteurs d'écran et les navigateurs, comme le souligne Scott O'Hara dans son article sur les éléments details et summary, certaines interactions ne montrent pas de changements importants lorsque les utilisateurs interagissent avec elles. Vous pourriez donc probablement l'améliorer avec JavaScript pour prendre en charge ces cas, mais l'accessibilité de ce composant est plutôt excellente par défaut, notamment pour la navigation au clavier, qui est notre principale préoccupation dans cet article !

Voici la structure HTML :

<details>
  <summary>
    <h2>Titre</h2>
    <span aria-hidden="true"></span>
  </summary>
  <p>
    <!-- Contenu -->
  </p>
</details>

Et voici à quoi cela ressemblerait lorsque les composants sont dans leur état contracté et développé :

Commençons maintenant à styliser ce composant ! Par défaut, cet élément utilise ce triangle pour indiquer si l'élément détails est ouvert ou fermé. Nous pouvons supprimer cela en ajoutant cette règle à l'élément summary.

summary {
  list-style: none;
}

Mais nous aurons toujours besoin d'un indicateur visuel pour montrer s'il est ouvert ou fermé. Ma solution consiste à ajouter un deuxième élément en tant qu'enfant de summary. La partie importante est que cet élément aura l'attribut aria-hidden="true" :

<summary>
  <p>Combien coûte l'expédition ?</p>
  <span aria-hidden="true"></span>
</summary>

La raison pour laquelle j'ai caché cet élément span est que nous allons modifier son contenu à l'aide de CSS modifiant le pseudo-élément ::before, et que le contenu que nous ajoutons sera lu par un lecteur d'écran, à moins, bien sûr, que nous le cachions.

Cela dit, nous pouvons le modifier car le navigateur gère l'état ouvert de l'élément details en ajoutant l'attribut open au conteneur. Nous pouvons donc ajouter et modifier le contenu à l'aide de ces règles CSS :

summary span[aria-hidden='true']::before {
  content: '+';
}
details[open] summary span[aria-hidden='true']::before {
  content: '-';
}

Maintenant, vous pouvez ajouter le style dont vous avez besoin pour l'adapter (n'oubliez pas d'utiliser les états de focus adéquats !). Vous pouvez consulter cette démo que j'ai réalisée pour voir comment cela fonctionne. Testez-la avec un clavier, et vous remarquerez que vous pouvez interagir avec elle sans problème.

voirDetails and summary demode smashingmag dansCodePen

Comme je l'ai mentionné, cette approche ne nécessite aucun JavaScript, mais ce n'est pas le seul modèle que vous pouvez utiliser pour le balisage ! Si vous voulez en savoir plus sur le balisage des composants en accordéon, vous pouvez lire cet article de Sara Soueidan à ce sujet.

Sauter les liens

Parfois, lorsque vous naviguez sur un site, vous pouvez trouver de grands blocs d'éléments focalisables par le clavier, comme dans un menu, par exemple. Or bien souvent l'utilisateur veut juste interagir avec le contenu principal (main), donc offrir un moyen de sauter ces blocs d'éléments interactifs est important . Il existe même un critère WCAG pour ce cas.

C'est là que les "liens de saut" entrent en jeu ! Les liens de saut sont des liens qui ne sont généralement visibles que lorsqu'un utilisateur appuie sur la touche Tab, et qui vous permettent d'accéder aux points d'intérêt d'une page. Normalement, c'est pour vous amener au contenu principal, comme vous pouvez le remarquer sur YouTube, par exemple :

Mais il peut y avoir plusieurs liens de saut dans un site qui vous mèneront à diverses parties du site, comme le fait Smashing Magazine. Lorsque vous utilisez la touche de tabulation pour naviguer sur ce site, vous remarquerez qu'il y a trois liens de saut, qui vous amènent tous à des points importants de la page :

Ils sont généralement situés dans le header du site, mais ce n'est pas toujours le cas. Vous pouvez les ajouter là où c'est nécessaire, comme le montre Manuel Matuzović dans le tweet qui suit. Il a ajouté un lien de saut inline à un projet parce que la carte interactive comporte beaucoup d'éléments focalisables avec le clavier.

Maintenant, puisque l'utilité des liens de saut est claire, créons-en un. C'est très simple, il nous suffit de créer un élément a qui vous amène à l'élément souhaité :

<header>
  <a class="skip-link" href="#main-content">Go to main content</a>
</header>
<main id="main-content"></main>

Ensuite, nous devons masquer visuellement l'élément a. Ce que je fais ici, c'est utiliser la propriété CSS transform pour le retirer de la portée visuelle :

.skip-link {
  display: block;
  transform: translate(-9999px);
}

Ensuite, nous le déplaçons à la position nécessaire lorsque l'élément est focalisé :

.skip-link:focus {
  transform: translate(0);
}

Et c'est tout ! La création d'un lien de saut est facile et bien utile pour l'accessibilité au clavier.

Tooltips

Ces petites bulles de texte qui affichent des informations supplémentaires sur un élément peuvent également être réalisées avec du CSS pur, mais un petit avertissement ici : il est suggéré que vous pouvez fermer une infobulle en appuyant sur la touche Echap, ce qui n'est possible qu'avec JavaScript. J'expliquerai comment ajouter cette fonctionnalité dans la deuxième partie de cet article, mais tout le reste peut être fait de manière très simple en utilisant uniquement HTML et CSS.

Un problème courant avec les infobulles est qu'un utilisateur du clavier ne peut pas les voir, nous devons donc nous assurer que le composant qui les déclenche est un élément focalisable par le clavier. Notre meilleure chance est d'utiliser l'élément bouton. La sémantique est vraiment simple, comme le montre Heydon Pickering dans son livre Inclusive Components.

<div class="tooltip-container">
  <button></button>
  <div role="tooltip"></div>
</div>

Le conteneur avec la classe tooltip-container est là juste pour nous permettre de manipuler la position du conteneur avec l'attribut role="tooltip" plus tard en utilisant CSS. A propos de cet élément, on pourrait penser que ce rôle ajoute suffisamment de sémantique pour le faire fonctionner, mais en fait, ce n'est pas le cas, nous devrons donc compter sur deux d'attributs aria pour le lier à notre bouton.

Cet attribut dépend de l'intention de l'infobulle. Si vous envisagez de l'utiliser pour nommer un élément, vous devez utiliser l'attribut aria-labelledby :

<div class="tooltip-container">
  <button aria-labelledby="tooltip1">
    <svg aria-hidden="true">
      <!-- Contenu du SVG -->
    </svg>
  </button>
  <div id="tooltip1" role="tooltip">Parc d'achat</div>
</div>

Par contre, si vous souhaitez utiliser l'infobulle pour décrire ce que fait un élément, vous devrez le lier à l'aide de l'attribut aria-describedby :

<div class="tooltip-container">
  <button aria-label="Panier d'achat" aria-describedby="tooltip2">
    <svg aria-hidden="true">
      <!-- Contenu du SVG -->
    </svg>
  </button>
  <div id="tooltip2" role="tooltip">
    Vérifier, modifier et terminer votre achat
  </div>
</div>

Soyez prudent avec cette approche ; utilisez-la uniquement pour donner des descriptions auxiliaires, et non pour donner des informations absolument nécessaires pour comprendre ce que fait cet élément. En effet, lorsqu'un utilisateur de lecteur d'écran génère une liste des éléments de formulaire (y compris les boutons) du site, la description ne s'affichera que si l'utilisateur se concentre sur l'élément, comme le montre Adrian Roselli dans son test sur l'attribut aria-description.

Maintenant, il est temps de parler de ce qui nous préoccupe dans cet article : l'accessibilité au clavier ! Pour cela, nous devons masquer l'infobulle et l'afficher jusqu'à ce que l'utilisateur place le pointeur sur l'élément ou qu'il le fasse avec un clavier. Pour cela, nous utiliserons les pseudo-classes :hover et :focus en tandem avec le combinateur adjacent sibling.

Par ailleurs, il est important que vous puissiez voir l'infobulle lorsque vous la survolez afin de respecter le critère WCAG 1.4.13 : Content on Hover or Focus. Avec ces considérations à l'esprit, voici à quoi devrait ressembler notre code :

[role='tooltip'] {
  position: absolute;
  bottom: 0;
  gauche: 50%;
  display: none;
  transform: translate(-50%, 100%);
}
button:hover + [role='tooltip'],
button:focus + [role='tooltip'],
[role='tooltip']:hover {
  display: block;
}

Et voilà comment créer une infobulle accessible au clavier à l'aide de HTML et CSS. Vous pouvez vérifier le comportement des deux exemples d'infobulles dans cette démo. N'oubliez pas que ce n'est pas entièrement prêt pour la production. Vous avez besoin de JavaScript pour fermer l'infobulle lorsque vous appuyez sur la touche Echap. Nous aborderons ce point plus tard dans la prochaine partie de cet article, alors gardez-le à l'esprit.

voirTooltip demo - CSS onlyde smashingmag dansCodePen

Comme le mentionne Heydon dans son livre, les infobulles ont un problème lorsque vous les utilisez pour des appareils qui n'ont pas de pointeur, comme les téléphones portables ou les tablettes, il faut alors adopter une approche différente pour elles. Vous pouvez utiliser CSS pour cela en utilisant les media queries hover et pointer, comme je l'explique dans mon article.

Récapitulatif

L'accessibilité du clavier est une partie essentielle de l'accessibilité. J'espère que cet article vous a aidé à comprendre à quel point HTML et CSS sont cruciaux pour faire de la navigation au clavier une expérience utilisateur agréable et accessible. Mais ce n'est pas la fin de l'accessibilité du clavier ! Je vais aborder la façon dont nous pouvons utiliser JavaScript pour manipuler la navigation au clavier et comment nous pouvons l'utiliser dans des modèles de composants plus complexes.

Lire la deuxième partie dans La Cascade

L'Initiative pour l'accessibilité du Web - Applications Internet riches accessibles (WAI-ARIA) est une spécification technique qui fournit des directives sur la manière d'améliorer l'accessibilité des applications Web. Alors que les directives d'accessibilité au contenu Web (WCAG) se concentrent davantage sur le contenu Web statique, WAI-ARIA s'attache à rendre les interactions plus accessibles.

Les interactions sur le Web sont connues pour être inaccessibles, alors qu'elles font souvent partie des fonctions les plus critiques telles que :

• la soumission d'une demande d'emploi,
• l'achat dans un magasin en ligne, ou
• la réservation d'un rendez-vous médical.

Je suis actuellement responsable de l'innovation en matière d'accessibilité chez Fable, une entreprise qui met en relation des organisations avec des personnes handicapées pour des recherches sur les utilisateurs et des tests d'accessibilité, et qui propose des formations personnalisées aux équipes numériques afin qu'elles acquièrent les compétences nécessaires à la création de produits inclusifs.

En tant qu'instructeur pour le développement Web accessible, je passe beaucoup de temps à examiner le code source des sites Web et des applications Web, et ARIA est l'une des choses que je vois les développeurs utiliser le plus mal.

HTML

Lorsque vous utilisez des éléments HTML tels que input, select et button, il se passe deux choses concernant l'accessibilité : les informations sur l'élément sont transmises au DOM (Document Object Model) et dans un arbre d'accessibilité. Les technologies d'assistance peuvent accéder aux nœuds de l'arbre d'accessibilité pour comprendre :

• de quel type d'élément il s'agit en vérifiant son rôle, par exemple, une case à cocher ;
• dans quel état se trouve l'élément, par exemple, coché/non coché ;
• le nom de l'élément, par exemple, "Inscrivez-vous à notre bulletin d'information".

L'autre chose que vous obtenez en utilisant les éléments HTML est l'interactivité du clavier. Par exemple, une case à cocher peut être mise en focus à l'aide de la touche de tabulation et sélectionnée à l'aide de la barre d'espacement (les interactions spécifiques peuvent varier selon le navigateur et le système d'exploitation, mais le fait est qu'elles sont disponibles et normalisées sur tous les sites Web lorsque vous utilisez des éléments HTML).

Lorsque vous n'utilisez pas les éléménts HTML modernes, par exemple, si vous construisez votre propre sélection personnalisée à l'aide de <div> et de <span> ou si vous utilisez une bibliothèque de composants, vous devez faire un travail supplémentaire pour fournir des informations sur l'élément et construire l'interactivité du clavier pour les utilisateurs de technologies d'assistance. C'est là que l'ARIA entre en jeu.

ARIA

Les applications Internet riches accessibles (ARIA) comprennent un ensemble de rôles et d'attributs qui définissent les moyens de rendre le contenu et les applications Web plus accessibles aux personnes handicapées.

Vous pouvez utiliser ARIA pour transmettre des informations à l'arbre d'accessibilité. Les rôles et attributs ARIA n'incluent pas d'interactivité avec le clavier. L'ajout de role="button" à une <div> ne le fait pas réagir lorsque vous appuyez sur la touche Entrée de votre clavier — cela, vous devez le construire en utilisant JavaScript ou un autre langage. Toutefois, le guide ARIA des pratiques de création de site comprend une liste de l'interactivité du clavier décrivant ce qui qui devrait être ajouté à divers composants tels que les accordéons, les boutons, les carrousels, etc.

Rôles

Commençons par les rôles. Qu'est-ce que c'est que ce truc dans le code ci-dessous ?

<div className="dd-wrapper">
  <div className="dd-header">
    <div className="dd-header-title"></div>
  </div>
  <div className="dd-list">
    <button className="dd-list-item"></button>
    <button className="dd-list-item"></button>
    <button className="dd-list-item"></button>
  </div>
</div>

Il s'agit en fait d'un extrait de code que j'ai trouvé en ligne à partir d'un élément select pour React. L'élément est complètement méconnaissable à partir du code, et c'est exactement le problème que rencontrerait toute technologie d'assistance — elle ne peut pas dire à l'utilisateur ce qu'est cet élément ni comment interagir avec lui car il n'y a pas de rôle ARIA.

Regardez ce que nous pouvons faire ici :

<div className="dd-wrapper" role="listbox"></div>

Peut-être ne connaissez-vous pas bien les listbox, c'est un type de select qu'un utilisateur de lecteur d'écran pourrait reconnaître et avec lequel il saurait interagir. Maintenant, vous pourriez simplement utiliser <select>, et vous n'auriez pas à lui donner de rôle car il en a déjà un que le DOM et l'arbre d'accessibilité reconnaîtront, mais je sais que ce n'est pas toujours une option réalisable.

Un rôle indique à un utilisateur de technologie d'assistance ce qu'est la chose avec laquelle il peut interagir, alors assurez-vous d'utiliser le bon rôle. Un bouton est très différent d'une bannière. Choisissez un rôle qui correspond à la fonction du composant que vous construisez.

Une autre chose que vous devez savoir sur les rôles ARIA est qu'ils remplacent le rôle inhérent d'un élément HTML.

<img role="button" />

Il ne s'agit plus d'une image mais d'un bouton. Il y a très peu de raisons de faire cela, et à moins de savoir exactement ce qu'on fait et pourquoi, je m'abstiendrais de remplacer les rôles HTML existants. Il existe de nombreuses autres façons d'y parvenir qui sont plus logiques du point de vue de l'accessibilité et de la robustesse du code :

<button><img src="image.png" alt="Imprimer" /></button>
<input type="image" src="image.png" alt="Imprimer" />
<button style="background : url(image.png)" />Imprimer</button>

Si vous créez un composant, vous pouvez consulter le modèle de ce composant dans Le guide ARIA des bonnes pratiques de construction de sites, qui contient des informations sur le ou les rôles à utiliser. Vous pouvez également consulter tous les rôles disponibles dans la documentation Web mdn.

En résumé, si vous construisez un élément qui n'a pas de balise HTML sémantique pour le décrire (c'est-à-dire tout élément interactif construit à l'aide de <div> ou <span>), il doit avoir un rôle ARIA pour que les technologies d'assistance puissent reconnaître ce qu'il est.

États et propriétés (également appelés attributs ARIA)

En plus de savoir ce qu'est un élément, s'il a un état (par exemple, caché, désactivé, invalide, en lecture seule, sélectionné, etc.) ou change d'état (par exemple, coché/non coché, ouvert/fermé, etc.), vous devez indiquer aux utilisateurs de technologies d'assistance quel est son état actuel et son nouvel état chaque fois qu'il change. Vous pouvez également partager certaines propriétés d'un élément. La différence entre les états et les propriétés n'est pas vraiment claire ou importante, alors appelons-les simplement des attributs.

Voici quelques-uns des attributs ARIA les plus courants que vous pourriez être amenés à utiliser :

• aria-checkedIl est utilisé avec ="true" ou ="false" pour indiquer si les cases à cocher et les boutons radio sont actuellement cochés ou non.
• aria-currentIl est utilisé avec ="true" ou ="false" pour indiquer la page actuelle dans le fil d'Ariane ou la pagination.
• aria-describedbyElle est utilisée avec l'id d'un élément pour ajouter plus d'informations à un champ de formulaire en plus de son étiquette. aria-describedby peut être utilisée pour donner des exemples du format requis pour un champ, par exemple une date, ou pour ajouter un message d'erreur à un champ de formulaire.

<label for="anniversaire">Anniversaire</label>
<input type="text" id="birthday" aria-describedby="date-format" />
<span id="date-format">MM-DD-YYYY</span>

• aria-expandedIl est utilisé avec ="true" ou ="false" pour indiquer si le fait d'appuyer sur un bouton affichera plus de contenu. Les exemples incluent les accordéons et les éléments de navigation avec sous-menus.

<button aria-expanded="false">Produits</button>

Ceci indique que le menu Produits ouvrira un sous-menu (par exemple, de différentes catégories de produits). En revanche, si vous le codez comme ceci...

<a href="/produits/">Produits</a>

...l'utilisateur s'attendra à ce qu'il s'agisse d'un lien et à ce qu'en cliquant dessus, il accède à une nouvelle page. Ce que le bouton plus aria-expanded dit à un utilisateur de technologie d'assistance, c'est qu'il ne va pas vers une nouvelle page, mais qu'il reste en fait sur la même page et ouvre un sous-menu. Cette simple différence entre <bouton> et <a> et l'ajout d'aria-expanded communique tellement sur la façon d'interagir avec les éléments et ce qui se passera lorsque vous le ferez.

• aria-hiddenIl est utilisé avec ="true" ou ="false" pour cacher quelque chose qui est visible, mais que vous ne voulez pas que les utilisateurs de technologies d'assistance connaissent. Utilisez-le avec une extrême prudence car il y a très peu de cas où vous ne voulez pas que des informations équivalentes soient présentées.

Un cas d'utilisation intéressant que j'ai vu est une carte comportant à la fois une image et le titre textuel de la carte renvoyant à la même page, mais structurée comme deux liens distincts. Imaginez un grand nombre de ces cartes sur une page. Pour un utilisateur de lecteur d'écran, il entendrait chaque lien lu deux fois. Les liens d'image ont donc utilisé aria-hidden="true". La solution idéale serait de combiner les liens en un seul qui contiendrait à la fois une image et le titre du texte, mais le codage dans la vie réelle n'est pas toujours idéal et vous n'avez pas toujours ce niveau de contrôle.

Notez que cela enfreint la quatrième règle d'ARIA (que nous aborderons plus tard), mais d'une manière qui ne nuit pas à l'accessibilité. Utilisez-la avec une extrême prudence lorsqu'il n'existe pas de meilleure solution de contournement et que vous l'avez testée avec des utilisateurs de technologies d'assistance.

• aria-requiredIl est utilisé avec ="true" ou ="false" pour indiquer si un élément de formulaire doit être rempli pour que le formulaire puisse être soumis.

Si vous construisez un composant, vous pouvez consulter les attributs de ce composant dans le guide des pratiques de création ARIA. La docs web mdn couvre les états et les propriétés ainsi que les rôles ARIA.

Gardez à l'esprit que tous ces attributs ARIA indiquent quelque chose à l'utilisateur, mais que vous devez toujours coder la chose que vous lui dites. aria-checked="true" ne vérifie pas réellement une case à cocher ; il indique simplement à l'utilisateur que la case est cochée, donc il vaut mieux que ce soit vrai ou vous aggraverez les choses au lieu de les améliorer pour l'accessibilité. L'exception serait aria-hidden="true" qui supprime un élément de l'arbre d'accessibilité, le cachant effectivement à toute personne utilisant une technologie d'assistance qui ne peut pas voir.

Nous savons donc maintenant comment utiliser ARIA pour expliquer ce qu'est un élément, dans quel état il se trouve et quelles sont ses propriétés. La dernière chose que je vais aborder est la gestion du focus.

Gestion du focus

Tout ce qui est interactif sur un site Web ou une application Web doit pouvoir recevoir le focus. Tout le monde n'utilise pas une souris, un trackpad ou un écran tactile pour interagir avec les sites. De nombreuses personnes utilisent leur clavier ou un dispositif technologique d'assistance qui émule un clavier. Cela signifie que pour tout ce sur quoi vous pouvez cliquer, vous devez également être capable d'utiliser la touche de tabulation ou les touches fléchées pour l'atteindre et la touche Entrée, et parfois la barre d'espacement, pour le sélectionner.

Il y a trois concepts dont vous devrez tenir compte si vous utilisez <div> et <span> pour créer des éléments interactifs :

1. Vous devez ajouter tabindex="0" pour qu'un clavier ou un émulateur puisse se concentrer sur eux.
2. Pour tout ce qui accepte la saisie au clavier, vous devez ajouter un écouteur d'événements (Event Listener) pour écouter les pressions sur les touches.
3. Vous devez ajouter le rôle approprié pour qu'un utilisateur de lecteur d'écran puisse identifier l'élément que vous avez construit.

N'oubliez pas que les contrôles HTML natifs acceptent déjà le focus et l'entrée clavier et ont des rôles inhérents. C'est exactement ce que vous devez faire lorsque vous créez des éléments personnalisés à partir de HTML non sémantique.

Ben Myers fait une plongée profonde dans la transformation d'une div en bouton, et je vais partager quelques extraits de son exemple ici. Remarquez le tabindex et le role :

<div tabindex="0" role="button" onclick="doSomething() ;">
  Cliquez sur moi !
</div>

Et vous aurez besoin de JavaScript pour écouter les pressions sur les touches :

const ENTER = 13
const SPACE = 32
// Sélectionnez votre bouton et enregistrez-le dans 'myButton'.
myButton.addEventListener('keydown', function (event) {
  if (event.keyCode === ENTER || event.keyCode === SPACE) {
    event.preventDefault() // Empêche les soumissions involontaires de formulaires, les défilements de pages, etc.
    doSomething(event)
  }
})

Lorsqu'il s'agit de déterminer les touches à écouter, je vous suggère de consulter le composant que vous construisez dans le guide des pratiques de création ARIA et de suivre les recommandations relatives à l'interaction avec le clavier.

Erreurs courantes

Pour avoir examiné beaucoup de code au cours de ma vie, je peux attester que certaines erreurs d'accessibilité sont régulièrement commises. Voici une liste des erreurs les plus courantes que je trouve et comment les éviter :

Utilisation d'un attribut aria-labelledby faisant référence à un ID qui n'existe pas

Par exemple, une modale qui a un titre dans la modale mais dont l'attribut aria-labelledby fait référence à quelque chose d'autre qui n'existe plus. C'est probablement quelque chose qui a été supprimé par un autre développeur qui n'a pas réalisé que la connexion aria-labelledby était là. Pour éviter cela, le titre de la modale aurait pu être un <h1> et soit aria-labelledby aurait pu faire référence au <h1>, soit on aurait pu mettre le focus sur le <h1> lorsque la modale s'ouvre et, du coup, un utilisateur de lecteur d'écran pourrait savoir ce qui se passe, tant que role="dialog" est également utilisé. Essayez d'éviter les structures fragiles qui, si quelqu'un d'autre venait à modifier le code, se briseraient facilement.

Ne pas déplacer le focus dans la nouvelle modale lorsqu'elle s'ouvre

Combien de fois ai-je vu un utilisateur de lecteur d'écran continuer à naviguer sur la page située sous la modale, parce qu'il ne savait pas qu'une modale s'était ouverte, soit être complètement perdu parce qu'il ne trouvait pas le contenu de la modale. Il existe plusieurs façons de déplacer le focus au sein d'une modale, mais l'une des méthodes les plus récentes consiste à ajouter inert au repère <main> (et, bien sûr, s'assurer que la modale n'est pas à l'intérieur de <main>). Inert bénéficie d'une meilleure prise en charge par les navigateurs ces derniers temps. Pour en savoir plus, consultez l'article de Lars Magnus Klavenes intitulé Accessible modal dialogs using inert.

Ajout de rôles qui font double emploi avec le HTML

En général, il est inutile d'écrire <button role="button">. Il existe un cas où il pourrait être judicieux de le faire. VoiceOver et Safari suppriment la sémantique des éléments de liste lorsque list-style : none est utilisé. C'est fait exprès car si rien n'indique à un utilisateur voyant que le contenu est une liste, pourquoi dire à un utilisateur de lecteur d'écran qu'il s'agit d'une liste ? Si vous voulez passer outre, vous pouvez ajouter un role="list" ARIA explicite à <ul>.

Adrian Roselli dit qu'une liste non stylisée n'étant pas annoncée comme une liste "...peut ne pas être un gros problème à moins que les tests utilisateurs disent que vous avez vraiment besoin d'une liste." Je suis d'accord avec lui sur ce point, mais je suis aussi d'accord avec la correction si vos tests utilisateurs montrent que c'est bénéfique.

Ajout de tabindex="0" à tous les éléments

Parfois, les développeurs commencent à utiliser un lecteur d'écran et supposent que la tabulation est la seule façon de naviguer et que, par conséquent, tout ce qui ne comporte pas de tabindex n'est pas accessible. Ce n'est PAS vrai. N'oubliez pas que si vous ne savez pas comment utiliser un lecteur d'écran, vous ne pouvez pas résoudre les problèmes d'utilisabilité. Rencontrez un utilisateur quotidien de lecteur d'écran pour les résoudre.

Utilisation de rôles enfants sans rôles parents

Par exemple, role="option" doit avoir un parent direct avec role="listbox".

<div role="listbox">
  <ul>
    <li role="option"></li>
  </ul>
</div>

Le code ci-dessus n'est pas valide car il y a un <ul> entre les éléments parent et enfant. Cela peut être corrigé en ajoutant un rôle de présentation pour essentiellement cacher le <ul> de l'arbre d'accessibilité, comme <ul role="presentation">.

Utilisation de role="menu" pour la navigation

La navigation d'un site Web est en réalité une table des matières et non un menu. Les menus ARIA ne sont pas destinés à être utilisés pour la navigation mais pour le comportement des applications, comme les menus d'une application de bureau. Utilisez plutôt <nav>, et si vous avez des liens de navigation enfants, ceux-ci doivent être cachés jusqu'à ce qu'on appuie sur un bouton pour les afficher :

<nav aria-label="Main menu">
  <button aria-expanded="false">Produits</button>
  <ul hidden>
    <li>Pyjama chat</li>
    ...
  </ul>
</nav>

Si vous voulez en savoir plus, Heydon Pickering fait une plongée profonde dans la construction de systèmes de menus accessibles dans son article de Smashing Magazine.

En ce qui concerne la navigation, utiliser <nav> plusieurs fois sur une page sans donner à chaque instance une étiquette unique signifie que les utilisateurs de lecteurs d'écran devront explorer chaque région de navigation pour trouver celle qu'ils recherchent. Un simple aria-label sur chaque <nav> rendra les choses beaucoup plus faciles.

<nav aria-label="Service client">
  <ul>
    <li><a href="#">Aide</a></li>
    <li><a href="#">Suivi des commandes</a></li>
    <li><a href="#">Expédition et livraison</a></li>
    <li><a href="#">Retours</a></li>
    <li><a href="#">Nous contacter</a></li>
    <li><a href="#">Trouver un magasin</a></li>
  </ul>
</nav>

Comment valider ARIA

Utilisez des vérificateurs d'accessibilité automatisés comme Axe ou les extensions WAVE lorsque vous exécutez votre code dans un navigateur. Les vérificateurs d'accessibilité comme Axe pour Visual Studio Code ou ESLint pour les éléments JSX vérifieront votre code à mesure que vous l'écrivez.

Écoutez votre code avec un lecteur d'écran. De même que vous ne publierez jamais un code sans l'exécuter dans un navigateur pour vous assurer qu'il fonctionne, de même l'utilisation d'un lecteur d'écran vous permettra de vérifier qu'il fonctionne pour tous les publics. NVDA est gratuit pour Windows, et VoiceOver est intégré aux Mac et iPhones. TalkBack est intégré aux téléphones Android.

Testez avec des utilisateurs de technologies d'assistance. Je considère cela comme obligatoire pour toute grande organisation qui dispose d'un budget pour l'accessibilité (et elles devraient toutes le faire). Il existe des entreprises qui peuvent recruter des utilisateurs de technologies d'assistance pour les tests ou effectuer des tests utilisateurs pour vous, et l'entreprise pour laquelle je travaille peut fournir des délais de 2 jours pour les tests utilisateurs qui sont, ou non, modérés par vous pour soutenir les tests d'accessibilité à grande échelle.

Frameworks et bibliothèques de composants

Si vous utilisez un framework Web, une façon d'alléger un peu le travail de construction pour l'accessibilité est d'utiliser une bibliothèque de composants intégrant l'accessibilité. J'ajouterai une mise en garde toutefois : l'accessibilité peut être complexe et tout ce qui se prétend accessible n'est pas toujours utilisable par les utilisateurs de technologies d'assistance. La meilleure façon de garantir l'accessibilité est de toujours tester avec les utilisateurs pour lesquels vous construisez.

Voici quelques points de départ pour votre recherche :

• React Aria
• Vue A11y
• Material Design 3
• Lion
• Open UI

Conclusion

Avec un peu de chance, cet article aura démystifié ARIA pour vous. Comme un langage secret connu de la seule l'élite de l'accessibilité, il a ses propres règles Fight Club-esque.

La première règle de l'ARIA est "N'utilisez pas l'ARIA". Un <button> sera toujours mieux que <div role="button">.Deuxièmement, ne remplacez pas la sémantique native. Au lieu de <button role="heading">, utilisez <h3><button>.Enfin, n'oubliez jamais que tous les éléments interactifs ARIA doivent fonctionner avec le clavier.N'utilisez pas role="presentation" ou aria-hidden="true" sur un élément focalisable. <button role="presentation"> signifie que vous cachez ce bouton uniquement aux utilisateurs de technologies d'assistance. Ce n'est pas seulement inaccessible, c'est carrément exclure certains utilisateurs.Dernier point, mais non le moindre, tous les éléments interactifs doivent avoir un nom accessible. Il existe de nombreuses façons de le faire, et en voici quelques-unes :

<button>Imprimer</button> (le nom est le texte du bouton)
<div aria-label="Settings"><svg></div> (l'aria-label attribue un nom)
<div aria-labelledby="myName">
  <h1 id="myName">La rubrique</h1>
</div>
<label for="name">Nom</label>
<input type="text" id="name" />

Je pense volontiers à ARIA comme à un outil utilisé par l'équipe d'élite des opérations spéciales à laquelle vous faites appel pour vos défis d'accessibilité les plus difficiles. Peut-être ai-je juste toujours voulu faire des pompes à un bras comme Emily Blunt dans Edge of Tomorrow, et c'est ce qui s'en rapproche le plus. Quoi qu'il en soit, j'espère que tout ceci vous a été utile et que vous n'êtes plus confus au sujet d'ARIA. Allez-y et construisez des choses accessibles !

Que nous vient-il à l'esprit lorsque nous pensons à une liste ? Le premier exemple peut-être, le plus évident, est la liste de courses — la plus simple des listes, une collection d'articles sans ordre particulier. Mais nous utilisons les listes de toutes sortes de façons sur le Web. Une série de concerts à venir ? Très probablement une liste. Un processus de réservation en plusieurs étapes ? Sans doute une liste. Une galerie d'images ? Même elle pourrait être considérée comme une liste d'images avec des légendes.

Dans cet article, nous allons nous plonger dans les différents types de listes HTML disponibles sur le Web et savoir quand les utiliser, y compris certains attributs que vous ne connaissez peut-être pas. Nous examinerons également quelques façons utiles et créatives de leur appliquer un style avec CSS.

Quand utiliser une liste ?

Un élément de liste HTML doit être utilisé lorsque des éléments doivent être regroupés de manière sémantique. Les technologies d'assistance (comme les lecteurs d'écran) signaleront à l'utilisateur la présence d'une liste et le nombre d'éléments. Si vous pensez, par exemple, à une grille de produits sur un site d'achat, connaître cette information serait très utile. Par conséquent, l'utilisation d'un élément de liste pourrait être un bon choix.

Types de liste

En ce qui concerne le balisage, nous avons le choix entre trois éléments de liste différents :

• Liste non ordonnée
• Liste ordonnée
• Liste de description

Le choix de l'une ou l'autre dépend du cas d'utilisation.

Liste non ordonnée (ul)

L'élément liste non ordonnée (<ul>) est le plus utile lorsque les éléments de la liste ne correspondent à aucun ordre particulier. Par défaut, il s'affiche sous la forme d'une liste à puces. Un exemple est une liste de courses, où l'ordre n'a pas d'importance.

Un exemple plus courant sur le Web est le menu de navigation. Quand on crée un menu, il convient d'envelopper le ul dans un élément nav et d'identifier le menu avec une étiquette, pour aider les technologies d'assistance. Nous devons également identifier la page actuelle dans le menu, ce que nous pouvons faire en utilisant l'attribut aria-current :

<nav aria-label="Navigation principale">
  <ul>
    <li>
      <a href="/page-1" aria-current="page">Elément de menu 1</a>
    </li>
    <li>
      <a href="/page-2">Elément de menu 2</a>
    </li>
    <li>
      <a href="/page-2">Menu élément 2</a>
    </li>
    ...
  </ul>
</nav>

Cet article sur la structure des menus présente un certain nombre de recommandations pour garantir que nos menus de navigation soient accessibles à tous.

Liste ordonnée (ol)

Un élément de liste ordonnée (<ol>) est le meilleur choix lorsque l'ordre des éléments est important, comme dans le cas d'un processus en plusieurs étapes. Par défaut, les éléments de la liste sont numérotés. Un exemple pourrait être un ensemble d'instructions, où les étapes doivent être accomplies dans l'ordre.

voirOrdered listde Web.dev dansCodePen

Les éléments <ol> et <ul> ne peuvent contenir que des éléments <li> comme enfants directs.

Liste de description (dl)

Une liste de description contient des termes (éléments <dt>) et des descriptions (<dd>). Chaque terme peut être accompagné de plus d'une description. Les cas d'utilisation possibles pourraient inclure un glossaire de termes, ou peut-être un menu de restaurant. Les listes de descriptions ne sont pas affichées avec des marqueurs par défaut, bien que les navigateurs aient tendance à indenter l'élément <dd>.

En HTML, il est permis de regrouper des termes avec les descriptions qui les accompagnent à l'aide d'un élément <div>. Cela peut être utile à des fins de style, comme nous le verrons plus tard.

<dl>- Ceci est valide -->
<dl>
    <dt>Terme 1</dt>
    <dd>C'est la première description du premier terme de la liste</dt>.
    <dd>C'est la deuxième description du premier terme de la liste</dt>
    <dt>Terme 2</dt>
    <dd>C'est la description du deuxième terme de la liste</dd>
</dl>
<!-- Ceci est également valable -->
<dl>
    <div>
        <dt>Terme 1</dt>
        <dd>C'est la première description du premier terme de la liste</dd>.
        <dd>C'est la deuxième description du premier terme de la liste</dd>
    </div>
    <div>
        <dt>Terme 2</dt>
        <dd>C'est la description du deuxième terme de la liste</dd>
    </div>
</dl>

Style de liste simple

L'une des utilisations les plus simples d'une liste est dans un bloc de texte du <body>. Très souvent, ces listes simples n'ont pas besoin d'un style élaboré, mais nous pourrions vouloir personnaliser les marqueurs d'une liste ordonnée ou non ordonnée dans une certaine mesure, par exemple avec une couleur de marque (brand), ou en utilisant une image personnalisée pour nos puces. Nous pouvons faire beaucoup de choses avec list-style et le pseudo-élément ::marker !

Pour vous rafraîchir la mémoire sur les bases du style de liste, consultez le tutoriel de web.dev Apprendre le CSS, ainsi qu'une plongée en profondeur dans l'utilisation de ::marker dans ce guide sur les puces personnalisées. Continuez à lire pour découvrir des choses que vous ne savez peut-être pas encore !

::marker

En plus de donner à nos marqueurs de liste un style de base, nous pouvons créer des puces cycliques. Ici, nous utilisons trois URL d'images différentes pour la valeur de contenu du pseudo-élément ::marker, ce qui ajoute à l'aspect manuscrit de notre exemple de liste de courses (au lieu d'utiliser une seule image pour tout) :

::marker {
  content: url('/marker-1.svg') ' ';
}
li:nth-child(3n)::marker {
  content: url('/marker-2.svg') ' ';
}
li:nth-child(3n - 1)::marker {
  content: url('/marker-3.svg') ' ';
}

voirHandwritten shopping list with custom markersde Web.dev dansCodePen

Compteur personnalisé

Pour certaines listes ordonnées, nous pourrions vouloir utiliser la valeur du compteur, mais y ajouter une autre valeur. Nous pouvons utiliser le compteur list-item comme valeur pour la propriété content de notre marqueur et y ajouter tout autre contenu :

::marker {
  content: counter(list-item) '? ';
}

voirHandwritten list with custom markersde Web.dev dansCodePen

Nos compteurs s'incrémentent automatiquement de un, mais nous pouvons leur permettre de s'incrémenter d'une valeur différente si nous le souhaitons, en définissant la propriété counter-increment sur l'élément de la liste. Par exemple, ceci incrémentera nos compteurs de trois à chaque fois :

li {
  counter-increment: list-item 3;
}

Nous pourrions approfondir bien d'autres choses avec les compteurs. L'article Listes, marqueurs et compteurs CSS de Rachel Andrew explique certaines des possibilités plus en détail.

Limites de la stylisation de ::marker

Nous souhaitons parfois avoir plus de contrôle sur la position et le style de nos marqueurs. Il n'est pas possible de positionner le marqueur à l'aide de flexbox ou de grid, par exemple, ce qui peut parfois être un inconvénient si vous avez besoin d'un autre alignement. ::marker expose un nombre limité de propriétés CSS pour le style. Si notre conception nécessite autre chose qu'un style de base, il est préférable d'utiliser un autre pseudo-élément.

Styliser des listes qui ne ressemblent pas à des listes

Parfois, nous souhaitons donner à nos listes un style totalement différent du style par défaut. C'est souvent le cas avec un menu de navigation, par exemple, où nous souhaitons généralement supprimer tous les marqueurs, et pourrions afficher notre liste horizontalement, à l'aide de flexbox. Une pratique courante consiste à régler la propriété list-style sur none. Cela signifie que le pseudo-élément ::marker ne sera plus accessible dans le DOM.

AttentionUn mot d'avertissement : list-style : none fera que Safari ne reconnaîtra plus une liste non ordonnée dans l'arbre d'accessibilité, et par conséquent qu'un lecteur d'écran n'annoncera plus les informations utiles telles que le nombre d'éléments. Une solution simple (en supposant que votre liste doive être lue comme telle) consiste à utiliser role="list" sur l'élément* <ul> ou <ol> *de votre HTML, comme le recommande l'expert en accessibilité Scott O'Hara.*

Marqueurs personnalisés avec ::before

L'utilisation du pseudo-élément ::before était un moyen courant de créer des marqueurs de liste personnalisés avant l'arrivée de ::marker. Mais même aujourd'hui, il peut nous offrir plus de flexibilité, lorsque nous en avons besoin, pour le style visuellement complexe des listes.

Comme pour ::marker, nous pouvons ajouter nos propres styles de puce personnalisés en utilisant l'attribut content. Contrairement à l'utilisation de ::marker, nous devons effectuer un positionnement manuel, car nous ne bénéficions pas des avantages automatiques offerts par list-style-position. Mais nous pouvons la positionner relativement facilement avec flexbox, ce qui ouvre un plus grand nombre de possibilités d'alignement. Par exemple, nous pourrions alterner la position du marqueur :

voirAlternating listde Web.dev dansCodePen

Si nous stylisons une liste ordonnée à l'aide de l'élément ::before, nous pouvons également souhaiter utiliser des compteurs pour ajouter nos marqueurs numériques.

li::before {
  counter-increment: list-item;
  content: counter(list-item);
}

voirAlternating listde Web.dev dansCodePen

L'utilisation de ::before au lieu de ::marker nous permet d'accéder pleinement aux propriétés CSS pour un style personnalisé, ainsi que de permettre des animations et des transitions — pour lesquelles la compatibilité est limitée pour ::marker.

Attributs de liste

Les éléments de listes ordonnées acceptent certains attributs facultatifs, qui peuvent nous aider dans bon nombre de cas d'utilisation.

Listes inversées

Si nous disposons d'une liste des 10 meilleurs albums de l'année dernière, nous pourrions vouloir effectuer un compte à rebours de 10 à 1. Nous pourrions utiliser des compteurs personnalisés pour cela, et les incrémenter négativement. Ou bien nous pourrions simplement utiliser l'attribut reversed dans le HTML. Je dirais qu'il est généralement plus judicieux, d'un point de vue sémantique, d'utiliser l'attribut reversed plutôt que d'incrémenter négativement le compteur dans le CSS, à moins que les compteurs n'aient qu'une valeur de présentaton. Si le CSS ne se charge pas, vous verrez quand même les chiffres décomptés correctement dans le HTML. En outre, nous devons tenir compte de la manière dont un lecteur d'écran interpréterait la liste.

Prenez cette démonstration des 10 meilleurs albums de 2021. Si les compteurs étaient incrémentés uniquement à l'aide de CSS, une personne accédant à la page à l'aide d'un lecteur d'écran pourrait en conclure que les chiffres comptent vers le haut, de sorte que le numéro 10 est en fait le numéro 1.

voirReversed listde Web.dev dansCodePen

Vous pouvez voir dans la démo qu'en utilisant l'attribut inversé, nos marqueurs ont déjà la valeur correcte, sans aucun effort supplémentaire de notre part ! Mais si nous créons des marqueurs de liste personnalisés en utilisant le pseudo-élément ::before, nous devons ajuster nos compteurs. Il nous suffit d'indiquer à notre compteur list-item de s'incrémenter négativement :

li::before {
  counter-increment: list-item -1;
  content: counter(list-item);
}

voirReversed list with ::beforede Web.dev dansCodePen

Diviser les listes

L'attribut start nous permet de spécifier la valeur numérique à partir de laquelle la liste doit commencer. Cela peut notamment être utile dans les cas où vous souhaitez diviser une liste en groupes.

Reprenons notre exemple des 10 meilleurs albums. Peut-être voulons-nous en fait décompter les 20 meilleurs albums, mais par groupes de 10. Entre les deux groupes, il y a un autre contenu de page.

Nous devrons créer deux listes distinctes dans notre HTML, mais comment nous assurer que les compteurs seront corrects ? Dans l'état actuel de notre balisage, les deux listes compteront de 10 à 1, ce qui n'est pas ce que nous voulons. Cependant, dans notre HTML, nous pouvons spécifier une valeur d'attribut de début (start). Si nous ajoutons une valeur de départ de 20 à notre première liste, les marqueurs seront à nouveau mis à jour automatiquement !

<ol reversed start="20">
  <li>...</li>
  <li>...</li>
  <li>...</li>
</ol>

voirReversed and split listde Web.dev dansCodePen

voirReversed and split list with ::beforede Web.dev dansCodePen

Affichage de la liste sur plusieurs colonnes

La disposition en plusieurs colonnes se prête parfois bien à nos listes, comme vous pouvez le constater dans les démos précédentes. En définissant une largeur de colonne, nous pouvons faire en sorte que notre liste soit automatiquement réactive et ne s'étende sur deux colonnes ou plus que lorsque l'espace est suffisant. Nous pouvons également définir un espace entre les colonnes et, pour une touche supplémentaire, ajouter une règle de colonne stylisée (en utilisant une abréviation similaire à la propriété border) :

ol {
  columns: 25rem;
  column-gap: 7rem;
  column-rule: 4px dotted turquoise;
}

En utilisant des colonnes, nous pouvons parfois nous retrouver avec des ruptures disgracieuses dans nos éléments de liste — pas toujours l'effet recherché.

Nous pouvons empêcher ces ruptures forcées en utilisant break-inside : avoid sur nos éléments de liste :

li {
  break-inside: avoid;
}

Propriétés personnalisées

Les propriétés personnalisées CSS offrent un large éventail de possibilités pour le style des listes. Si nous connaissons l'index de l'élément de la liste, nous pouvons l'utiliser pour calculer les valeurs des propriétés. À l'heure actuelle malheureusement, il n'existe aucun moyen de déterminer l'index de l'élément (de manière utilisable en CSS uniquement, en tout cas). Les compteurs nous permettent uniquement d'utiliser leur valeur dans la propriété content, et ne permettent pas les calculs.

Mais nous pouvons définir l'index de l'élément dans l'attribut style de notre HTML, ce qui peut rendre les calculs plus réalisables, surtout si nous utilisons un langage de templating. Cet exemple montre comment nous pourrions définir cela en utilisant Nunjucks :

<ol style="--length : items|length">
  {% for item in items %}
  <li style="--i : {{ loop.index }}">...</li>
  {% endfor %}
</ol>

Splitting.js est une bibliothèque qui exécute une fonction similaire du côté client.

En utilisant la valeur de la propriété personnalisée, la progression dans une liste peut être affichée de différentes manières. Une façon pourrait être une barre de progression pour une liste d'étapes. Dans cet exemple, nous utilisons un pseudo-élément avec un dégradé linéaire afin de créer une barre pour chaque élément qui indique à quel point l'utilisateur est avancé dans la liste.

li::before {
  --stop: calc(100% / var(--longueur) * var(--i));
  --color1: deeppink;
  --couleur2: rose;
  content: '';
  background: linear-gradient(
    to right,
    var(--color1) var(--stop),
    var(--color2) 0
  );
}

voirCustom properties step progress indicatorde Web.dev dansCodePen

Nous pouvons également ajuster la teinte à mesure qu'on progresse dans la liste, en utilisant la fonction de couleur hsl(). Nous pouvons calculer la valeur de la teinte en utilisant notre propriété personnalisée.

voirCustom properties step progress indicatorde Web.dev dansCodePen

Stylisation de la liste des descriptions

Comme nous l'avons mentionné précédemment, nous pouvons choisir d'envelopper les termes et leurs définitions dans une div ou dans une dl, pour nous donner plus d'options de style. Par exemple, nous pourrions vouloir afficher notre liste sous forme de grille. Si vous définissez display : grid sur la liste sans placer une div autour de chaque groupe, les termes et les descriptions seront placés dans des cellules de grille différentes. C'est parfois utile, comme dans l'exemple suivant, qui montre un menu de tartes avec leurs descriptions.

Nous pouvons définir une grille sur la liste elle-même et nous assurer que les termes et les descriptions seront toujours alignés en colonnes, la largeur de la colonne étant déterminée par le terme le plus long.

voirPie menude Web.dev dansCodePen

D'un autre côté, si nous voulons regrouper distinctement les termes avec leurs descriptions à la manière d'une carte, un wrapper <div> est très utile.

voirPie menude Web.dev dansCodePen

Ressources complémentaires

• Listes, Une introduction de web.dev aux listes et à ::marker
• Listes, dans les Fondamentaux du texte HTML par MDN
• Marqueurs personnalisés à l'aide de ::marker
• ::marker, par MDN
• Listes CSS avec compteurs, de Rachel Andrew

Dans un article précédent, j'ai examiné la capacité de CSS Grid à créer des mises en page complexes en utilisant ses pouvoirs d'auto-placement. Je suis allé plus loin dans un autre article qui ajoutait un effet de zoom au survol des images dans une disposition en grille. À présent, je veux me plonger dans un autre type de grille, celle qui fonctionne avec des formes.

Par exemple, que faire si les images ne sont pas parfaitement carrées mais ont plutôt la forme d'hexagones ou de losanges ? spoiler : nous pouvons le faire. En fait, nous allons combiner les techniques de grille CSS que nous avons déjà examinées et ajouter un peu de magie CSS de type clip-path et mask pour créer des grilles d'images fantaisistes pour pratiquement toutes les formes que vous pouvez imaginer !

Commençons par un balisage

La plupart des mises en page que nous allons examiner peuvent sembler faciles à réaliser à première vue, mais le défi consiste à les réaliser avec le même balisage HTML. Nous pouvons utiliser beaucoup de wrappers, de divs et autres, mais l'objectif de cet article est d'utiliser la même quantité de code HTML, et la plus petite possible, pour obyenir toutes les différentes grilles. Après tout, qu'est-ce que CSS sinon un moyen de séparer le style et le balisage ? Notre style ne doit pas dépendre du balisage, et vice versa.

Ceci étant dit, commençons :

<div class="gallery">
  <img src="..." alt="..." />
  <img src="..." alt="..." />
  <img src="..." alt="..." />
  <img src="..." alt="..." />
  <!-- autant de fois que l'on veut -->
</div>

Tout ce dont nous avons besoin ici, c'est d'un conteneur avec des images. Rien de plus !

Grille CSS d'hexagones

Cette grille est aussi parfois appelée "nid d'abeille".

voirHoneycomb image galleryde Temani Afif dansCodePen

Il y a déjà beaucoup d'autres articles de blog qui montrent comment faire cela. J'en ai même écrit un ici sur CSS-Tricks ! Cet article est toujours bon et explique en détail comment créer une mise en page réactive. Mais pour ce cas précis, nous allons nous appuyer sur une approche CSS beaucoup plus simple.

Tout d'abord, utilisons le clip-path sur les images pour créer la forme hexagonale et plaçons-les toutes dans la même zone de grille pour qu'elles se chevauchent.

.gallery {
  --s : 150px ; /* contrôle la taille */
  display : grid ;
}
.gallery > img {
  grid-area : 1/1 ;
  width : var(--s) ;
  aspect-ratio : 1.15 ;
  object-fit : couverture ;
  clip-path : polygon(25% 0%, 75% 0%, 100% 50%, 75% 100%, 25% 100%, 0 50%) ;
}

Rien de bien original pour l'instant. Toutes les images sont des hexagones et sont superposées. Il semble que nous n'ayons qu'un seul élément d'image en forme d'hexagone, mais en réalité il y en a sept.

voirUntitledde Temani Afif dansCodePen

L'étape suivante consiste à appliquer une translation aux images pour les placer correctement sur la grille.

Remarquez que nous voulons toujours qu'une des images reste au centre. Les autres sont placées autour d'elle en utilisant CSS translate et la bonne vieille géométrie. Voici les formules que j'ai créées pour chaque image de la grille :

translate((height + gap)*sin(0deg), (height + gap)*cos(0))
translate((height + gap)*sin(60deg), (height + gap)*cos(60deg))
translate((height + gap)*sin(120deg), (height + gap)*cos(120deg))
translate((height + gap)*sin(180deg), (height + gap)*cos(180deg))
translate((height + gap)*sin(240deg), (height + gap)*cos(240deg))
translate((height + gap)*sin(300deg), (height + gap)*cos(300deg))

Quelques calculs et optimisations plus tard (sautons cette partie ennuyeuse, d'accord ?), nous obtenons le CSS suivant :

.gallery {
  --s: 150px; /* contrôle de la taille */
  --g: 10px; /* contrôle de l'espacement */
  display: grid;
}
.gallery > img {
  grid-area: 1/1;
  width: var(--s);
  aspect-ratio: 1.15;
  object-fit: cover;
  clip-path: polygon(
    25% 0%,
    75% 0%,
    100% 50%,
    75% 100%,
    25% 100%,
    0 50%
  );
  transform: translate(var(--_x, 0), var(--_y, 0));
}
.gallery > img:nth-child(1) {
  --_y: calc(-100% - var(--g));
}
.gallery > img:nth-child(7) {
  --_y: calc(100% + var(--g));
}
.gallery > img:nth-child(3),
.gallery > img:nth-child(5) {
  --_x: calc(-75% - 0.87 * var(--g));
}
.gallery > img:nth-child(4),
.gallery > img:nth-child(6) {
  --_x: calc(75% + 0.87 * var(--g));
}
.gallery > img:nth-child(3),
.gallery > img:nth-child(4) {
  --_y: calc(-50% - 0.5 * var(--g));
}
.gallery > img:nth-child(5),
.gallery > img:nth-child(6) {
  --_y: calc(50% + 0.5 * var(--g));
}

?? Ce sera peut-être plus facile lorsque nous aurons de vraies fonctions de trigonométrie en CSS !

Chaque image est traduite par les variables --_x et --_y qui sont basées sur ces formules. Seule la deuxième image (nth-child(2)) est indéfinie dans tout sélecteur car c'est celle qui se trouve au centre. Il peut s'agir de n'importe quelle image si vous décidez d'utiliser un ordre différent. Voici l'ordre que j'utilise :

Avec seulement quelques lignes de code, nous obtenons une super grille d'images. À cela, j'ai ajouté un petit effet de survol aux images pour rendre les choses plus fantaisistes.

Et devinez quoi ? Nous pouvons obtenir une autre grille hexagonale en mettant simplement à jour quelques valeurs.

voirAnother hexagon gridde Temani Afif dansCodePen

Si vous vérifiez le code et le comparez avec le précédent, vous remarquerez que j'ai simplement interverti les valeurs à l'intérieur de clip-path et que j'ai permuté entre --x et --y. C'est tout !

Grille CSS de losanges

Ce losange est juste un carré qui a subi une rotation de 45 degrés.

voirRhombus image galleryde Temani Afif dansCodePen

Même HTML, vous vous souvenez ? Nous commençons par définir une grille d'images 2×2 en CSS :

.gallery {
  --s: 150px; /* contrôle la taille */
  display: grid;
  gap: 10px;
  grid: auto-flow var(--s) / repeat(2, var(--s));
  place-items: center;
}
.gallery > img {
  width: 100%;
  aspect-ratio: 1;
  object-fit: cover;
}

La première chose qui pourrait attirer votre attention est la propriété grid. Elle n'est pas souvent utilisée, mais elle est très utile car il s'agit d'un raccourci qui nous permet de définir une grille complète en une seule déclaration. Ce n'est pas la propriété la plus intuitive — sans parler de la lisibilité — mais nous sommes ici pour apprendre et découvrir de nouvelles choses, alors utilisons-la plutôt que d'écrire toutes les propriétés individuelles de la grille.

grid: auto-flow var(--s) / repeat(2, var(--s));
/* est équivalent à ceci : */
grid-template-columns: repeat(2, var(--s));
grid-auto-rows: var(--s);

Cela définit deux colonnes de largeur égale à la variable --s et fixe la hauteur de toutes les lignes à --s également. Comme nous avons quatre images, nous obtiendrons automatiquement une grille de 2×2.

Voici une autre façon dont nous aurions pu l'écrire :

grid-template-columns: repeat(2, var(--s));
grid-template-rows: repeat(2, var(--s));

...ce qui peut être réduit avec le raccourci grid :

grid: repeat(2, var(--s)) / repeat(2, var(--s));

Après avoir défini la grille, nous la faisons pivoter ainsi que les images avec des transformations CSS et nous obtenons ceci :

voirUntitledde Temani Afif dansCodePen

Notez comment je les fais pivoter tous les deux de 45deg, mais dans la direction opposée.

.gallery {
  /* etc. */
  transform: rotate(45deg);
}
.gallery > img {
  /* etc. */
  transform: rotate(-45deg);
}

La rotation des images dans le sens négatif les empêche de subir une rotation avec la grille, elles restent donc droites. Maintenant, nous appliquons un clip-path pour découper une forme de losange à partir des images.

voirUntitledde Temani Afif dansCodePen

Nous avons presque terminé ! Nous devons rectifier la taille des images pour qu'elles s'emboîtent. Sinon, elles sont très espacées au point que cela ne ressemble pas à une grille d'images.

L'image se trouve à l'intérieur de la limite du cercle vert, qui est le cercle inscrit de la zone de la grille où l'image est placée. Ce que nous voulons, c'est agrandir l'image pour qu'elle rentre dans le cercle rouge, qui est le cercle circonscrit de la zone de la grille.

Ne vous inquiétez pas, je ne présenterai pas de géométrie plus ennuyeuse. Tout ce que vous devez savoir, c'est que le rapport entre le rayon de chaque cercle est la racine carrée de 2 (sqrt(2)). C'est la valeur dont nous avons besoin pour augmenter la taille de nos images afin de remplir la zone. Nous utiliserons 100%*sqrt(2) = 141% et le tour est joué !

.gallery {
  --s: 150px; /* contrôle de la taille */
  display: grid;
  grid: auto-flow var(--s) / repeat(2, var(--s));
  gap: 10px;
  place-items: center;
  transform: rotate(45deg);
}
.gallery > img {
  width: 141%; /* 100%*sqrt(2) = 141% */
  aspect-ratio: 1;
  object-fit: cover;
  transform: rotate(-45deg);
  clip-path: polygon(50% 0, 100% 50%, 50% 100%, 0 50%);
}

Comme pour la grille hexagonale, nous pouvons rendre les choses plus fantaisistes avec ce bel effet de survol de zoom :

voirRhombus image galleryde Temani Afif dansCodePen

Grille CSS de formes triangulaires

voirTriangular grid of imagesde Temani Afif dansCodePen

Vous savez probablement maintenant que la grande astuce consiste à déterminer le clip-path pour obtenir les formes que nous voulons. Pour cette grille, chaque élément a sa propre valeur de clip-path alors que les deux dernières grilles utilisaient des formes cohérentes. Donc, cette fois-ci, c'est comme si nous travaillions avec plusieurs formes triangulaires différentes qui s'assemblaient pour former une grille rectangulaire d'images.

Nous les plaçons dans une grille 3×2 avec le CSS suivant :

.gallery {
  display : grid ;
  gap : 10px ;
  grid-template-columns : auto auto auto ; /* 3 colonnes */
  place-items : center ;
}
.gallery > img {
  width : 200px ; /* contrôle la taille */
  aspect-ratio : 1 ;
  object-fit : cover ;
}
/* les valeurs de clip-path */
.gallery > img:nth-child(1) { clip-path : polygon(0 0, 50% 0, 100% 100% ,0 100%) ; }
.gallery > img:nth-child(2) { clip-path : polygon(0 0, 100% 0, 50% 100%) ; }
.gallery > img:nth-child(3) { clip-path : polygon(50% 0, 100% 0, 100% 100%, 0 100%) ; }
.gallery > img:nth-child(4) { clip-path : polygon(0 0, 100% 0, 50% 100%, 0 100%) ; }
.gallery > img:nth-child(5) { clip-path : polygon(50% 0, 100% 100%, 0% 100%) ; }
.gallery > img:nth-child(6) { clip-path : polygon(0 0, 100% 0 ,100% 100%, 50% 100%) ; } } }

Voici ce que nous obtenons :

voirUntitledde Temani Afif dansCodePen

La touche finale consiste à rendre la largeur de la colonne centrale égale à 0 pour se débarrasser des espaces entre les images. C'est le même genre de problème d'espacement que nous avions avec la grille de losanges, mais avec une approche différente pour les formes que nous utilisons maintenant :

grid-template-columns: auto 0 auto;

J'ai dû jouer avec les valeurs de clip-path pour m'assurer qu'elles s'emboîtent toutes comme un puzzle. Les images originales se chevauchent lorsque la colonne du milieu a une largeur nulle, mais après avoir découpé les images, l'illusion est parfaite :

Grille CSS en pizza

Devinez quoi ? Nous pouvons obtenir une autre grille cool en ajoutant simplement border-radius et overflow à notre grille ou à nos formes triangulaires. ?

voirPizza-like gridde Temani Afif dansCodePen

Grille CSS de pièces de puzzle

Cette fois, nous allons jouer avec la propriété CSS mask pour que les images ressemblent aux pièces d'un puzzle.

voirPuzzle-like grid of imagesde Temani Afif dansCodePen

Note : si vous n'avez pas encore utilisé mask avec les dégradés CSS, je vous recommande vivement cet autre article que j'ai écrit sur le sujet car il vous aidera pour la suite. Pourquoi des dégradés ? Parce que c'est ce que nous utilisons pour obtenir les encoches rondes dans les formes des pièces du puzzle.

La configuration de la grille devrait être un jeu d'enfant maintenant, alors concentrons-nous plutôt sur la partie masque.

voirUntitledde Temani Afif dansCodePen

Comme illustré dans la démo ci-dessus, nous avons besoin de deux dégradés pour créer la forme finale. Un dégradé crée un cercle (la partie verte) et l'autre crée la bonne courbe tout en remplissant la partie supérieure.

--g: 6px; /* contrôle le gap */
--r: 42px; /* contrôle les formes circulaires */
background: radial-gradient(
    var(--r) at left 50% bottom var(--r),
    green 95%,
    #0000
  ),
  radial-gradient(
      calc(var(--r) + var(--g)) at calc(100% + var(--g)) 50%,
      #0000 95%,
      red
    ) top/100% calc(100% - var(--r)) no-repeat;

Deux variables contrôlent la forme. La variable --g n'est rien d'autre que la gouttière de la grille. Nous devons tenir compte de celle-ci pour placer correctement nos cercles afin qu'ils se chevauchent parfaitement lorsque le puzzle entier est assemblé. La variable --r contrôle la taille des parties circulaires de la forme du puzzle.

Maintenant, nous prenons le même CSS et mettons à jour quelques valeurs dans celui-ci pour créer les trois autres formes :

voirUntitledde Temani Afif dansCodePen

Nous avons les formes, mais pas les bords superposés dont nous avons besoin pour les faire s'emboîter. Chaque image est limitée à la cellule de la grille dans laquelle elle se trouve, il est donc logique que les formes soient en quelque sorte mélangées pour le moment :

Nous devons créer un débordement en augmentant la hauteur/largeur des images. D'après la figure ci-dessus, nous devons augmenter la hauteur de la première et de la quatrième image tandis que nous augmentons la largeur de la deuxième et de la troisième. Vous avez probablement déjà deviné que nous devons les augmenter en utilisant la variable --r.

.gallery > img:is(:nth-child(1), :nth-child(4)) {
  width: 100%;
  height: calc(100% + var(--r));
}
.gallery > img:is(:nth-child(2), :nth-child(3)) {
  height: 100%;
  largeur: calc(100% + var(--r));
}

On s'approche !

voirUntitledde Temani Afif dansCodePen

Nous avons créé le chevauchement mais, par défaut, nos images se chevauchent soit à droite (si nous augmentons la largeur), soit en bas (si nous augmentons la hauteur). Mais ce n'est pas ce que nous voulons pour les deuxième et quatrième images. La solution est d'utiliser place-self: end sur ces deux images et notre code complet devient :

voirUntitledde Temani Afif dansCodePen

Voici un autre exemple où j'utilise un dégradé conique au lieu d'un dégradé radial. Cela nous donne des pièces de puzzle triangulaires tout en gardant les mêmes HTML et CSS sous-jacents.

voirPuzzle Grid of imagesde Temani Afif dansCodePen

Un petit dernier pour la route ! Cette fois-ci, j'utilise le clip-path, et comme il s'agit d'une propriété que nous pouvons animer, nous obtenons un survol cool en mettant simplement à jour la propriété personnalisée qui contrôle la forme.

voirPuzzle Grid of images with hover effectde Temani Afif dansCodePen

Depuis longtemps les développeurs front rêvent d'avoir un moyen d'appliquer le CSS à un élément en fonction de ce qui se passe à l'intérieur de cet élément.

Nous pourrions vouloir par exemple disposer un élément d'article d'une certaine façon s'il y a une image "héros" en haut, et d'une autre façon s'il n'y a pas d'image "héros". Ou peut-être voulons-nous appliquer des styles différents à un formulaire en fonction de l'état de l'un de ses champs de saisie. Que diriez-vous de donner à une barre latérale une couleur d'arrière-plan si un certain composant est présent dans cette barre latérale, et une couleur d'arrière-plan différente si ce composant n'est pas présent ? Les cas d'utilisation de ce type existent depuis longtemps et les développeurs Web ont approché à plusieurs reprises le groupe de travail CSS, les suppliant d'inventer un "sélecteur de parent".

Au cours des vingt dernières années, le groupe de travail CSS a discuté de cette possibilité à de très nombreuses reprises. Le besoin était clair et bien compris. Définir la syntaxe était une tâche réalisable. Mais trouver comment un moteur de navigateur pourrait traiter des patterns circulaires potentiellement très complexes et effectuer les calculs assez rapidement semblait impossible. Les premières versions d'un sélecteur de parent ont été ébauchées pour CSS3, mais elles ont été reportées. Finalement, la pseudo-classe :has() a été officiellement définie dans les sélecteurs CSS de niveau 4. Mais le fait de disposer d'une norme Web ne suffit pas à faire de :has() une réalité. Nous avions encore besoin d'une équipe chargée des navigateurs pour relever le défi très réel des performances. Pendant ce temps, les ordinateurs continuaient à devenir plus puissants et plus rapides chaque année.

En 2021, Igalia a commencé à plaider en faveur de :has() auprès des équipes d'ingénierie des navigateurs, en prototypant leurs idées et en documentant leurs conclusions concernant les performances. Le regain d'intérêt pour :has() a attiré l'attention des ingénieurs qui travaillent sur WebKit chez Apple. Nous avons commencé à implémenter la pseudo-classe, en réfléchissant aux possibilités d'amélioration des performances nécessaires pour que cela fonctionne. Nous avons discuté pour savoir s'il fallait commencer par une version plus rapide avec un champ d'application très limité, puis essayer de supprimer ces limites si possible... ou commencer par quelque chose qui n'avait aucune limite, et n'appliquer de restrictions que si nécessaire. Nous nous sommes lancés et avons implémenté la version la plus puissante. Nous avons développé un certain nombre de nouvelles optimisations de mise en cache et de filtrage spécifiques à :has, et nous avons exploité les stratégies d'optimisation avancées existantes de notre moteur CSS. Et notre approche a fonctionné, prouvant qu'après deux décennies d'attente, il est enfin possible d'implémenter un tel sélecteur avec des performances fantastiques, même en présence de grands arbres DOM et d'un grand nombre de sélecteurs :has().

L'équipe WebKit a livré :has() dans l'aperçu technologique 137 de Safari en décembre 2021, et dans Safari 15.4 le 14 mars 2022. Igalia a effectué le travail d'ingénierie pour implémenter :has() dans Chromium, qui sera livré dans Chrome 105 le 30 août 2022. On peut supposer que les autres navigateurs construits sur Chromium ne seront pas loin derrière. Mozilla travaille actuellement sur l'implémentation de Firefox.

Voyons donc, étape par étape, ce que les développeurs Web peuvent faire avec cet outil tant désiré. Il s'avère que la pseudo-classe :has() n'est pas seulement un "sélecteur de parent". Après des décennies d'impasses, ce sélecteur peut faire bien plus.

Les bases de :has() comme sélecteur de parent

Commençons par les bases. Imaginons que nous voulions appliquer un style à un élément <figure> en fonction du type de contenu de l'image. Parfois, notre figure n'englobe qu'une image.

<figure>
  <img src="flowers.jpg" alt="fleurs de printemps">
</figure>

Alors que d'autres fois, l'image comporte une légende.

<figure>
  <img src="chien.jpg" alt="chien noir souriant au soleil">
  <figcaption>Maggie adore être dehors sans laisse.</figcaption>
</figure>

Appliquons maintenant quelques styles à la figure qui ne s'appliqueront que s'il y a une figcaption à l'intérieur de la figure.

figure:has(figcaption) {
  background: white;
  padding: 0.6rem;
}

Ce sélecteur décrit exactement ce qu'il dit — tout élément figure ayant une figcaption sera sélectionné.

Voici la démo, si vous souhaitez modifier le code et voir ce qui se passe. Veillez à utiliser un navigateur qui prend en charge :has() — à ce jour, on parle de Safari.

voir:has() Demo #1 — Figure variationsde jensimmons dansCodePen

Dans cette démo, je cible également tout élément <figure> qui contient un élément <pre> en utilisant figure:has(pre).

figure:has(pre) {
  background: rgb(252, 232, 255);
  border: 3px solid white;
  padding: 1rem;
}

Et j'utilise une requête de fonctionnalité de sélecteur (Feature Query) pour masquer un rappel sur la prise en charge par le navigateur lorsque le navigateur actuel prend en charge :has().

@supports selector(:has(img)) {
  small {
    display: none;
  }
}

La règle-@ (at-rule) @supports selector() est elle-même très bien prise en charge. Elle peut être incroyablement utile chaque fois que vous voulez utiliser une requête de fonctionnalité pour tester la prise en charge par le navigateur d'un sélecteur particulier.

Et enfin, dans cette première démo, j'écris également un sélecteur complexe à l'aide de la pseudo-classe :not(). Je veux appliquer display : flex à la figure, mais seulement si le seul contenu est une image. Flexbox fait alors en sorte que l'image s'étire pour remplir tout l'espace disponible.

J'utilise un sélecteur pour cibler tout élément <figure> qui n'a pour enfant aucun élément autre que <img>. Si la figure a une figcaption, pre, p ou un h1 — ou tout autre élément que img — le sélecteur ne s'applique pas.

figure:not(:has(:not(img))) {
  affichage: flex;
}

:has() est sacrément puissant !

Un exemple pratique utilisant :has() avec CSS Grid

Regardons une deuxième démo où j'ai utilisé :has() comme sélecteur de parent pour résoudre facilement un besoin très pratique.

J'ai plusieurs cards (cartes ou encarts) pour des article mis en page à l'aide de CSS Grid. Certaines cartes ne contiennent que des titres et du texte, tandis que d'autres ont également une image. Je veux que les cartes avec des images prennent plus de place sur la grille que celles sans image.

Je ne veux pas avoir à faire un travail supplémentaire pour que mon système de gestion de contenu applique une classe ou utilise JavaScript pour la mise en page. Je veux juste écrire un simple sélecteur en CSS qui indiquera au navigateur de faire en sorte que toute carte contenant une image occupera deux lignes et deux colonnes dans la grille.

Avec la pseudo-classe :has() c'est très simple :

article:has(img) {
  grid-column: span 2;
  grid-row: span 2;
}

voir:has() Demo #2 — Teaser cardsde jensimmons dansCodePen

Ces deux premières démos utilisent des sélecteurs d'éléments simples datant des premiers jours de CSS, mais tous les sélecteurs peuvent être combinés avec :has(), y compris le sélecteur de classe, le sélecteur d'ID, le sélecteur d'attribut — et de puissants combinateurs, comme nous allons le voir maintenant.

Utiliser :has() avec le combinateur enfant

Tout d'abord, un bref rappel de la différence entre le combinateur descendant et le combinateur enfant (>). (?? NdT : pour un tour complet de la question, vous pouvez consulter l'article Combinateurs et pseudo-classes ici-même).

Le combinateur descendant existe depuis le tout début de CSS. Il s'écrit en mettant un espace entre deux sélecteurs simples :

a img {
  ...;
}

Cela cible tous les éléments img qui sont contenus dans un élément a, quelle que soit la distance entre le a et l'img dans l'arbre DOM HTML.

<a>
  <figure>
    <img
      src="photo.jpg"
      alt="n'oublie pas le texte alternatif"
      width="200"
      height="100"
    />
  </figure>
</a>

Le combinateur sécrit en mettant un > entre deux sélecteurs — ce qui indique au navigateur de cibler tout ce qui correspond au deuxième sélecteur, mais uniquement lorsque le deuxième sélecteur est un enfant direct du premier.

a > img {
  ...;
}

Par exemple, ce sélecteur cible tous les éléments img enveloppés par un élément a, mais uniquement lorsque l'img se trouve immédiatement après le a dans le HTML.

<a>
  <img
    src="photo.jpg"
    alt="n'oublie pas le texte alternatif"
    width="200"
    height="100"
  />
</a>

En gardant cela à l'esprit, examinons la différence entre les deux exemples suivants. Les deux sélectionnent l'élément a, plutôt que l'img, puisque nous utilisons :has().

a:has(img) {
  ...;
}
a:has(> img) {
  ...;
}

La première sélectionne tout élément a avec une img à l'intérieur — n'importe où dans la structure HTML. Alors que la seconde sélectionne un élément uniquement si l'img est un enfant direct de l'élément a.

Les deux peuvent être utiles ; ils accomplissent des choses différentes.

voir:has() Demo #3 — Descendant combinator vs Child combinatorde jensimmons dansCodePen

Il existe encore deux autres types de combinateurs — tous deux sont des frères et sœurs. Et c'est grâce à eux que :has() devient plus qu'un sélecteur de parent.

Utiliser :has() avec des combinateurs frères et sœurs

Passons en revue les deux sélecteurs de relations "fraternelles". Il y a le combinateur de next-siblings (+) et le combinateur subsequent-siblings (~) de frères et sœurs suivants.

Le combinateur next-sibling (+) sélectionne uniquement les paragraphes qui suivent directement un élément h2 :

h2 + p

<h2>Les titres</h2>
<p>
  Paragraphe qui est sélectionné par "h2 + p", car il se trouve
  directement après "h2".
</p>
.

Le combinateur subsequent-siblings (~) sélectionne tous les paragraphes qui viennent après un élément h2. Ils doivent être frères et sœurs, mais il peut y avoir un nombre quelconque d'autres éléments HTML entre les deux.

h2 ~ p

<h2>Les titres</h2>
<h3>Autre chose</h3>
<p>Paragraphe qui est sélectionné par "h2 ~ p".</p>
<p>Ce paragraphe est également sélectionné.</p>

Notez que h2 + p et h2 ~ p sélectionnent tous deux les éléments paragraphes, et non les titres h2. Comme d'autres sélecteurs (pensez à img), c'est le dernier élément listé qui est ciblé par le sélecteur. Mais que faire si nous voulons cibler le h2 ? Eh bien nous pouvons utiliser les combinateurs frères et sœurs avec :has().

Combien de fois avez-vous souhaité pouvoir ajuster les marges d'un titre en fonction de l'élément qui le suit ? C'est maintenant facile. Ce code nous permet de sélectionner tout h2 ayant un p immédiatement après lui.

h2:has(+ p) {
  margin-bottom: 0;
}

Incroyable.

Et si nous voulions faire cela pour les six éléments de titre, sans écrire six copies du sélecteur. Nous pouvons utiliser :is() pour simplifier notre code.

:is(h1, h2, h3, h4, h5, h6):has(+ p) {
  margin-bottom: 0;
}

Mais que faire si nous voulons écrire ce code pour plus d'éléments que de simples paragraphes ? Éliminons la marge inférieure de tous les titres lorsqu'ils sont suivis de paragraphes, de légendes, d'exemples de code et de listes :

:is(h1, h2, h3, h4, h5, h6):has(+ :is(p, figcaption, pre, dl, ul, ol)) {
  margin-bottom: 0;
}

La combinaison de :has() avec les combinateurs descendants, les combinateurs enfants (>), les combinateurs frères et sœurs suivants (+) et les combinateurs frères et sœurs subséquents (~) ouvre un monde de possibilités. Mais ce n'est encore que le début.

Styler les états de formulaire sans JS

Il y a beaucoup de pseudo-classes fantastiques qui peuvent être utilisées à l'intérieur de has:(). En fait, cela révolutionne ce que les pseudo-classes peuvent faire. Auparavant, les pseudo-classes n'étaient utilisées que pour styler un élément en fonction d'un état spécial, ou pour styler l'un de ses enfants. Maintenant, les pseudo-classes peuvent être utilisées pour capturer un état, sans JavaScript, et styler n'importe quoi dans le DOM en fonction de cet état.

Les champs de saisie des formulaires constituent un moyen puissant de capturer un tel état. Les pseudo-classes spécifiques aux formulaires incluent :autofill, :enabled, :disabled, :read-only, :read-write, :placeholder-shown, :default, :checked, :indeterminate, :valid, :invalid, :in-range, :out-of-range, :required et :optional.

Résolvons l'un des cas d'utilisation que j'ai décrits dans l'introduction — le besoin de longue date de styler une étiquette de formulaire en fonction de l'état du champ de saisie. Commençons par un formulaire de base.

<form>
  <div>
    <label for="name">Nom</label>
    <input type="text" id="name" />
  </div>
  <div>
    <label for="site">Site web</label>
    <input type="url" id="site" />
  </div>
  <div>
    <label for="email">Email</label>
    <input type="email" id="email" />
  </div>
</form>

J'aimerais appliquer un arrière-plan à l'ensemble du formulaire lorsque l'un des champs est en focus.

form:has(:focus-visible) {
  background: antiquewhite;
}

J'aurais pu utiliser form:focus-within à la place, mais cela se comporterait comme form:has(:focus). La pseudo-classe :focus applique toujours le CSS lorsqu'un champ est en focus. La pseudo-classe :focus-visible fournit un moyen fiable de styler un indicateur de focus uniquement lorsque le navigateur en dessinerait un nativement, en utilisant la même heuristique complexe que le navigateur utilise pour déterminer s'il faut ou non appliquer un anneau de focus.

Maintenant, imaginons que je veuille styler les autres champs, ceux qui ne sont pas en focus — en changeant la couleur du texte de leur étiquette et la couleur de la bordure de l'entrée. Avant :has(), cela nécessitait JavaScript. Maintenant, nous pouvons utiliser ce CSS.

form:has(:focus-visible) div:has(input:not(:focus-visible)) label {
  color: peru;
}
form:has(:focus-visible) div:has(input:not(:focus-visible)) input {
  border: 2px solid peru;
}

Que dit ce sélecteur ? Si l'un des contrôles de ce formulaire a le focus, et que l'élément d'entrée de ce contrôle de formulaire particulier n'a pas le focus, alors change la couleur du texte de cette étiquette en peru. Et change la bordure du champ de saisie pour qu'elle soit 2px solid peru.

Vous pouvez voir ce code en action dans la démo suivante en cliquant à l'intérieur d'un des champs de texte. L'arrière-plan du formulaire change, comme je l'ai décrit précédemment. Et les couleurs de l'étiquette et de la bordure de saisie des champs qui ne sont pas en focus changent également.

voir:has() Demo #4 — Form fieldsde jensimmons dansCodePen

Dans cette même démo, j'aimerais aussi améliorer l'avertissement à l'utilisateur lorsqu'il y a une erreur dans la façon dont il a rempli le formulaire. Depuis longtemps déjà, nous pouvons facilement mettre un encadré rouge autour d'une entrée invalide avec ce CSS.

input:invalid {
  outline: 4px solid red;
  border: 2px solid red;
}

Maintenant, avec :has(), nous pouvons également rendre le texte de l'étiquette rouge :

div:has(input:invalid) label {
  color: red;
}

Vous pouvez voir le résultat en tapant quelque chose dans le champ du site Web ou de l'adresse électronique qui n'est pas une URL ou une adresse électronique entièrement formée. Les deux sont invalides et déclenchent donc une bordure rouge et une étiquette rouge, avec un "X".

Basculement en mode sombre sans JS

Et enfin, dans cette même démo, j'utilise une case à cocher pour permettre à l'utilisateur de basculer entre un thème clair et un thème foncé.

body:has(input[type='checkbox']:checked) {
  background: blue;
  --primary-color: white;
}
body:has(input[type='checkbox']:checked) form {
  border: 4px solid white;
}
body:has(input[type='checkbox']:checked) form:has(:focus-visible) {
  background: navy;
}
body:has(input[type='checkbox']:checked) input:focus-visible {
  outline: 4px solid lightsalmon;
}

J'ai stylé la case à cocher du mode sombre à l'aide de styles personnalisés, mais elle ressemble toujours à une case à cocher. Avec des styles plus complexes, je pourrais créer une bascule (toggle) en CSS.

De la même façon, je pourrais utiliser un menu de sélection pour proposer à un utilisateur plusieurs thèmes pour mon site.

body:has(option[value='pony']:checked) {
  --font-family: cursive;
  --text-color: #b10267;
  --body-background: #ee458e;
  --main-background: #f4b6d2;
}

voir:has() Demo #5 — Theme picker via Selectde jensimmons dansCodePen

Chaque fois qu'il y a une occasion d'utiliser CSS au lieu de JavaScript, je la saisis. Cela permet d'obtenir une expérience plus rapide et un site Web plus robuste. JavaScript peut faire des choses incroyables, et nous devrions l'utiliser quand c'est le bon outil pour le travail. Mais si nous pouvons obtenir le même résultat en utilisant uniquement HTML et CSS, c'est encore mieux.

Et plus encore

En regardant les autres pseudo-classes, il y en a tellement qui peuvent être combinées avec :has(). Imaginez les possibilités avec :nth-child, :nth-last-child, :first-child, :last-child, :only-child, :nth-of-type, :nth-last-of-type, :first-of-type, :last-of-type, :only-of-type. La toute nouvelle pseudo-classe :modal est déclenchée lorsqu'un dialogue est dans l'état ouvert. Avec :has(:modal), vous pouvez donner un style à n'importe quoi dans le DOM selon que le dialogue est ouvert ou fermé.

Cependant, toutes les pseudo-classes ne sont pas actuellement prises en charge dans :has() dans tous les navigateurs, alors testez votre code dans plusieurs navigateurs. Actuellement, les pseudo-classes dynamiques de médias ne fonctionnent pas, comme :playing, :paused, :muted, etc. Elles pourraient très bien fonctionner à l'avenir, alors si vous lisez ceci dans quelques temps, testez-les ! De plus, la prise en charge de l'invalidation des formulaires est actuellement absente dans certaines situations spécifiques, donc les changements d'état dynamiques de ces pseudo-classes peuvent ne pas être mis à jour avec :has().

Safari 16 ajoutera la prise en charge de :has(:target), ce qui ouvrira des possibilités intéressantes pour écrire du code qui recherche dans l'URL actuelle un fragment correspondant à l'ID d'un élément spécifique. Par exemple, si un utilisateur clique sur une table des matières en haut d'un document et descend jusqu'à la section de la page correspondant à ce lien, :target permet de styler ce contenu de manière unique, en se basant sur le fait que l'utilisateur a cliqué sur le lien pour y arriver. Et :has() ouvre la voie aux possibilités d'un tel style.

À noter : le groupe de travail CSS a décidé d'interdire tous les pseudo-éléments existants à l'intérieur de :has(). Par exemple, article:has(p::first-line) et ol:has(li::marker) ne fonctionneront pas. Idem pour ::before et ::after.

La révolution :has()

C'est une petite révolution dans la façon d'écrire les sélecteurs CSS, qui ouvre un monde de possibilités jusqu'alors impossibles ou souvent sans intérêt. On a l'impression que même si nous reconnaissons immédiatement l'utilité de :has(), nous n'avons aucune idée de ce qui est vraiment possible. Au cours des prochaines années, les personnes qui réalisent des démonstrations et se plongent dans ce que CSS peut faire trouveront des idées incroyables, étirant :has() jusqu'à ses limites.

Michelle Barker a créé une démo fantastique qui déclenche l'animation des tailles de pistes d'une grille css grâce à l'utilisation de :has() et des états de survol. Vous pouvez en savoir plus à ce sujet dans son article de blog. La prise en charge des pistes de grille animées sera disponible dans Safari 16. Vous pouvez essayer cette démo aujourd'hui dans Safari Technology Preview ou Safari 16 beta.

La partie la plus difficile de :has() sera d'ouvrir nos esprits à ses possibilités. Nous nous sommes tellement habitués aux limites que nous impose l'absence de sélecteur de parent. Nous devons maintenant briser ces habitudes.

C'est aussi une raison supplémentaire d'utiliser le CSS pur sucre, et de ne pas se limiter aux classes définies dans un framework. En écrivant votre propre CSS, personnalisé pour votre projet, vous pouvez tirer pleinement parti de toutes les puissantes capacités des navigateurs d'aujourd'hui.

À quoi allez-vous utiliser :has() ? En décembre dernier, j'ai demandé sur Twitter quels cas d'utilisation les gens pourraient avoir pour :has(), et j'ai reçu de nombreuses réponses avec des idées incroyables. J'ai hâte de voir les vôtres.

Il est facile de créer une grille d'images, grâce à CSS Grid. Mais il n'est pas toujours évident de faire des choses amusantes avec la grille une fois les images placées.

Par exemple, vous voulez ajouter un effet de survol aux images pour qu'elles grandissent et s'agrandissent au-delà des rangées et des colonnes où elles se trouvent ? Nous pouvons le faire !

voirCSS grid with expandable imagesde Temani Afif dansCodePen

Cool, non ? Si vous vérifiez le code, vous ne trouverez pas de JavaScript, ni de sélecteurs complexes, ni même de chiffres magiques. Et ce n'est qu'un exemple parmi tant d'autres que nous allons explorer !

Création de la grille

Le code HTML pour créer la grille est aussi simple qu'une liste d'images dans un conteneur. Nous n'avons pas besoin de plus que cela.

<div class="gallery">
  <img />
  <img />
  <img />
  <!-- etc. -->
</div>

Pour le CSS, nous commençons par définir la grille en utilisant ce qui suit :

.gallery {
  --s: 150px; /* contrôle la taille */
  --g: 10px; /* contrôle les gouttières (gap) */
  display: grid;
  gap: var(--g);
  width: calc(
    3 * var(--s) + 2 * var(--g)
  ); /* 3 fois la taille plus 2 fois la gouttière */
  aspect-ratio: 1;
  grid-template-columns: repeat(3, auto);
}

En résumé, nous avons deux variables, l'une qui contrôle la taille des images et l'autre qui définit la taille de l'espace entre les images. L'aspect-ratio permet de garder les choses en proportion.

Vous vous demandez peut-être pourquoi nous ne définissons que trois colonnes et aucune rangée. Non, je n'ai pas oublié les rangées, mais nous n'avons pas besoin de les définir explicitement. CSS Grid est capable de placer automatiquement des éléments sur des rangées et des colonnes implicites, ce qui signifie qu'il nous fournit autant de rangées que nécessaire, quel que soit le nombre d'images que nous lui envoyons. Nous pouvons définir explicitement les rangées si nous le voulons, mais dans ce cas nous devons ajouter grid-auto-flow : column pour nous assurer que le navigateur créera les colonnes nécessaires pour nous.

Voici un exemple pour illustrer les deux cas. La différence est que l'un suit un flux dans le sens des rangées et l'autre dans le sens des colonnes.

voirdifference between row/columnde Temani Afif dansCodePen

Maintenant que notre grille est en place, il est temps d'ajouter un peu de style à nos images :

.gallery > img {
  width: 0;
  height: 0;
  min-height: 100%;
  min-width: 100%;
  object-fit: cover;
}

L'effet de survol que nous réalisons repose sur ce CSS. Il vous semblera probablement étrange que nous créions des images sans largeur ni hauteur, mais avec une largeur et une hauteur minimales de 100 %. Mais vous verrez qu'il s'agit d'une astuce assez pratique pour ce que nous essayons de réaliser.

Ce que je fais ici, c'est dire au navigateur que les images doivent avoir une largeur et une hauteur nulles, mais qu'elles doivent aussi avoir une hauteur minimale égale à 100 %... mais 100 % de quoi ? Lorsqu'on utilise des pourcentages, la valeur est relative à quelque chose d'autre. Dans notre cas, l'image est placée à l'intérieur d'une cellule de la grille et nous devons connaître sa taille pour savoir à quoi correspond le pourcentage de 100 %.

Le navigateur ignorera d'abord la valeur min-height : 100% pour calculer la taille des cellules de la grille, mais il utilisera la valeur height : 0 dans son calcul. Cela signifie que nos images ne contribueront pas à la taille des cellules de la grille... car elles n'ont techniquement aucune taille physique. Il en résultera trois colonnes et rangées égales basées sur la taille de la grille (que nous avons définie sur la largeur et le ratio d'aspect de la galerie). La hauteur de chaque cellule de la grille n'est rien d'autre que la variable --s que nous avons définie tout à l'heure (idem pour la largeur).

Maintenant que nous avons les dimensions des cellules de notre grille, le navigateur va l'utiliser avec min-height : 100% (et min-width : 100%) ce qui va forcer les images à remplir complètement l'espace de chaque cellule de la grille. Tout cela peut sembler un peu confus, mais l'idée principale est de s'assurer que la grille définit la taille des images plutôt que l'inverse. Je ne veux pas que l'image définisse la taille de la grille et vous comprendrez pourquoi lorsque nous aurons ajouté l'effet de survol.

Création de l'effet au survol

Ce que nous devons faire, c'est augmenter l'échelle des images lorsqu'elles sont survolées. Pour ce faire, nous pouvons ajuster la largeur et la hauteur de l'image au moment du :hover :

.gallery {
  --f: 1.5; /* contrôle le facteur d'échelle */
}
.gallery img:hover {
  width: calc(var(--s) * var(--f));
  height: calc(var(--s) * var(--f));
}

J'ai ajouté une nouvelle variable personnalisée, --f, au mélange comme facteur d'échelle pour contrôler la taille au survol. Remarquez que je multiplie la variable de taille, --s, par celle-ci pour calculer la nouvelle taille de l'image.

Mais tu avais dit que la taille de l'image doit être de 0. Que se passe-t-il ? Je suis perdu...

Ce que j'ai dit reste vrai, mais je fais une exception pour l'image survolée. Je dis au navigateur qu'une seule image aura une taille différente de zéro — elle contribuera donc à la dimension de la grille — tandis que toutes les autres resteront égales à 0.

La partie gauche montre la grille dans son état naturel, sans aucune image survolée, ce que montre la partie droite. Toutes les cellules de la grille sur le côté gauche sont de taille égale puisque toutes les images n'ont pas de dimensions physiques.

Sur le côté droit, la deuxième image de la première rangée est survolée, ce qui lui donne des dimensions qui affectent la taille de la cellule de la grille. Le navigateur agrandit cette cellule de grille spécifique au survol, ce qui contribue à la taille globale. Et comme la taille de l'ensemble de la grille est définie (puisque nous avons défini une largeur fixe pour la .galerie), les autres cellules de la grille vont logiquement répondre en devenant plus petites afin de conserver la taille globale de la .galerie.

C'est notre effet de zoom en action ! En augmentant la taille d'une seule image, nous affectons l'ensemble de la configuration de la grille, et nous avons dit précédemment que la grille définit la taille des images de sorte que chaque image s'étire dans sa cellule de grille pour remplir tout l'espace.

À cela, nous ajoutons une touche de transition et utilisons objet-fit pour éviter la distorsion des images et l'illusion est parfaite !

Je sais que la logique de cette astuce n'est pas facile à comprendre. Ne vous inquiétez pas si vous ne la comprenez pas complètement. Le plus important est de comprendre la structure du code utilisé et comment le modifier pour obtenir plus de variations. C'est ce que nous allons faire maintenant !

Ajout d'images supplémentaires

Nous avons créé une grille 3×3 pour expliquer l'astuce principale, mais vous avez deviné que nous n'avions pas besoin de nous arrêter là. Nous pouvons faire varier le nombre de colonnes et de rangées et ajouter autant d'images que nous le souhaitons.

voirVariable columns/rowsde Temani Afif dansCodePen

.gallery {
  --n: 3; /* nombre de lignes*/
  --m: 4; /* nombre de colonnes */
  --s: 150px; /* contrôle de la taille */
  --g: 10px; /* contrôle des gouttières */
  --f: 1.5; /* contrôle le facteur d'échelle */
  display: grid;
  gap: var(--g);
  width: calc(var(--m) * var(--s) + (var(--m) - 1) * var(--g));
  height: calc(var(--n) * var(--s) + (var(--n) - 1) * var(--g));
  grid-template-columns: repeat(var(--m), auto);
}

Nous avons deux nouvelles variables pour le nombre de lignes et de colonnes. Ensuite, nous définissons simplement la largeur et la hauteur de notre grille en les utilisant. Même chose pour grid-template-columns qui utilise la variable --m. Et comme précédemment, nous n'avons pas besoin de définir explicitement les rangées puisque la fonction de placement automatique de la grille CSS fera le travail pour nous, quel que soit le nombre d'éléments d'image que nous utilisons.

Pourquoi pas des valeurs différentes pour la largeur et la hauteur ? Nous pouvons le faire :

voirVariable width/heightde Temani Afif dansCodePen

.gallery {
  --n: 3; /* nombre de rangées*/
  --m: 4; /* nombre de colonnes */
  --h: 120px; /* contrôle de la hauteur */
  --w: 150px; /* contrôle la largeur */
  --g: 10px; /* contrôle des gouttières */
  --f: 1.5; /* contrôle le facteur d'échelle */
  display: grid;
  gap: var(--g);
  width: calc(var(--m) * var(--w) + (var(--m) - 1) * var(--g));
  height: calc(var(--n) * var(--h) + (var(--n) - 1) * var(--g));
  grid-template-columns: repeat(var(--m), auto);
}
.gallery img:hover {
  width: calc(var(--w) * var(--f));
  height: calc(var(--h) * var(--f));
}

Nous remplaçons --s par deux variables, une pour la largeur, --w, et une autre pour la hauteur, --h. Puis nous ajustons tout le reste en conséquence.

Nous avons donc commencé par une grille avec une taille et un nombre d'éléments fixes, mais nous avons ensuite créé un nouvel ensemble de variables pour obtenir la configuration que nous voulons. Tout ce que nous avons à faire est d'ajouter autant d'images que nous le souhaitons et d'ajuster les variables CSS en conséquence. Les combinaisons sont illimitées !

Une galerie d'images en plein écran

Et pourquoi pas une version plein écran ? Oui, c'est également possible. Tout ce dont nous avons besoin c'est de savoir quelles valeurs nous devons attribuer à nos variables. Si nous voulons N rangées d'images et que nous voulons que notre grille soit en plein écran, nous devons d'abord résoudre une hauteur de 100vh :

var(--n) * var(--h) + (var(--n) - 1) * var(--g) = 100vh

Même logique pour la largeur, mais en utilisant vw au lieu de vh :

var(--m) * var(--w) + (var(--m) - 1) * var(--g) = 100vw

On fait le calcul pour obtenir :

--w : (100vw - (var(--m) - 1) * var(--g)) / var(--m)
--h : (100vh - (var(--n) - 1) * var(--g)) / var(--n)

C'est fait !

voirFull screen gridde Temani Afif dansCodePen

Il s'agit exactement du même code HTML, mais avec quelques variables mises à jour qui modifient la taille et le comportement de la grille.

Notez que j'ai omis la formule que nous avions précédemment définie pour la largeur et la hauteur du .gallery et que je l'ai remplacée par 100vw et 100vh, respectivement. La formule nous donnera le même résultat mais comme nous savons quelle valeur nous voulons, nous pouvons nous débarrasser de toute cette complexité supplémentaire.

Nous pouvons également simplifier les formules --h et --w en supprimant la gouttière de l'équation en faveur de ceci :

--h: calc(
  100vh / var(--n)
); /* Hauteur de la fenêtre divisée par le nombre de rangées */
--w: calc(
  100vw / var(--m)
); /* Largeur de la fenêtre divisée par le nombre de colonnes */

L'image survolée sera donc un peu plus grande que dans l'exemple précédent, mais ce n'est pas grave puisque nous pouvons contrôler l'échelle avec la variable --f que nous utilisons comme multiplicateur.

Et puisque les variables sont utilisées à un seul endroit, nous pouvons encore simplifier le code en les supprimant complètement :

voirSimplifying the formula #2de Temani Afif dansCodePen

Il est important de noter que cette optimisation s'applique uniquement à l'exemple en plein écran et non aux exemples que nous avons couverts. Cet exemple est un cas particulier où nous pouvons alléger le code en supprimant une partie du travail de calcul complexe dont nous avions besoin dans les autres exemples.

Nous disposons en fait de tout ce dont nous avons besoin pour créer le modèle populaire de panneaux extensibles :

voirOne dimension gridde Temani Afif dansCodePen

Creusons encore plus profond

Avez-vous remarqué que notre facteur d'échelle peut être inférieur à 1 ? Nous pouvons définir la taille de l'image survolée comme étant inférieure à --h ou --w, mais l'image s'agrandit au survol.

La taille initiale de la cellule de la grille est égale à --w et --h, alors pourquoi une valeur plus petite rend-elle la cellule de la grille plus grande ? La cellule ne devrait-elle pas devenir plus petite, ou au moins conserver sa taille initiale ? Et quelle est la taille finale de la cellule de la grille ?

Nous devons approfondir la manière dont l'algorithme CSS Grid calcule la taille des cellules de la grille. Et cela implique de comprendre l'alignement extensible (stretch alignment) par défaut de CSS Grid.

Voici un exemple pour comprendre la logique.

voirUntitledde Temani Afif dansCodePen

Dans la partie gauche de la démo, j'ai défini une double colonne avec une largeur automatique. Nous obtenons le résultat intuitif : deux colonnes égales (et deux cellules de grille égales). Mais la grille que j'ai définie sur le côté droit de la démo, où je mets à jour l'alignement à l'aide de place-content : start, semble ne rien avoir.

DevTools nous aide en montrant ce qui se passe réellement dans les deux cas :

Dans la deuxième grille, nous avons deux colonnes, mais leurs largeurs sont égales à zéro, de sorte que nous obtenons deux cellules de grille qui sont effondrées dans le coin supérieur gauche du conteneur de la grille. Il ne s'agit pas d'un bogue mais du résultat logique de l'alignement de la grille. Lorsque nous dimensionnons une colonne (ou une rangée) avec auto, cela signifie que c'est son contenu qui dicte sa taille — mais nous avons une div vide sans contenu à placer.

Cependant, comme l'alignement par défaut est l'alignement stretch et que nous avons suffisamment d'espace à l'intérieur de notre grille, le navigateur va étirer les deux cellules de la grille de manière égale pour couvrir toute cette zone. C'est ainsi que la grille de gauche se retrouve avec deux colonnes égales.

Extrait de la spécification :

Notez que certaines valeurs de justify-content et align-content peuvent entraîner l'espacement des pistes (space-around, space-between, space-evenly) ou leur redimensionnement (stretch).

Notez le mot "redimensionner" qui est la clé ici. Dans le dernier exemple, j'ai utilisé place-content, qui est l'abréviation de justify-content et align-content.

Et ceci est caché quelque part dans les spécifications de l'algorithme de redimensionnement de la grille :

Cette étape développe les pistes qui ont une fonction de dimensionnement de piste max automatique en divisant tout espace libre positif et défini restant de manière égale entre elles. Si l'espace libre est indéfini, mais que le conteneur de la grille a une largeur/hauteur minimale définie, utilisez cette taille pour calculer l'espace libre pour cette étape.

L'expression "de manière égale" explique pourquoi nous nous retrouvons avec des cellules de grille égales, mais elle s'applique à "l'espace libre", qui est très important.

Reprenons l'exemple précédent et ajoutons du contenu à l'une des div :

voirUntitledde Temani Afif dansCodePen

Nous avons ajouté une image carrée de 50px. Voici une illustration de la façon dont chaque grille de notre exemple réagit à cette image :

Dans le premier cas, nous pouvons voir que la première cellule (en rouge) est plus grande que la seconde (en bleu). Dans le deuxième cas, la taille de la première cellule change pour s'adapter à la taille physique de l'image tandis que la deuxième cellule reste sans dimension. L'espace libre est divisé de manière égale, mais la première cellule a plus de contenu, ce qui la rend plus grande.

Voici le calcul pour déterminer notre espace libre :

(largeur de la grille) - (espace) - (largeur de l'image) = (espace libre)
200px - 5px - 50px = 145px

Divisé par deux — le nombre de colonnes — nous obtenons une largeur de 72,5px pour chaque colonne. Mais nous ajoutons la taille de l'image, 50px, à la première colonne, ce qui nous laisse une colonne de 122,5px et la seconde de 72,5px.

La même logique s'applique à notre grille d'images. Toutes les images ont une taille égale à 0 (aucun contenu), tandis que l'image survolée contribue à la taille — même si ce n'est que de 1px — rendant sa cellule de grille plus grande que les autres. Pour cette raison, le facteur d'échelle peut être n'importe quelle valeur supérieure à 0, même les décimales entre 0 et 1.

Pour obtenir la largeur finale des cellules de la grille, nous effectuons le même calcul pour obtenir ce qui suit :

(largeur du conteneur) - (somme de tous les espaces) - (largeur de l'image survolée) = (espace libre)

La largeur du conteneur est définie par :

var(--m)*var(--w) + (var(--m) - 1)*var(--g)

...et tous les espaces libres sont égaux à :

(var(--m) - 1)*var(--g)

...et pour l'image survolée nous avons :

var(--w)*var(--f)

Nous pouvons calculer tout cela avec nos variables :

var(--m)*var(--w) - var(--w)*var(--f) = var(--w)*(var(--m) - var(--f))

Le nombre de colonnes est défini par --m ,donc nous divisons cet espace libre de manière égale pour obtenir :

var(--w)*(var(--m) - var(--f))/var(--m)

...ce qui nous donne la taille des images non survolées. Pour les images survolées, nous avons ceci :

var(--w)*(var(--m) - var(--f))/var(--m) + var(--w)*var(--f)
var(--w)*((var(--m) - var(--f))/var(--m) + var(--f))

Si nous voulons contrôler la taille finale de l'image survolée, nous utilisons la formule ci-dessus pour obtenir la taille exacte que nous voulons. Si, par exemple, nous voulons que l'image soit deux fois plus grande :

(var(--m) - var(--f))/var(--m) + var(--f) = 2

Ainsi, la valeur de notre multiplicateur d'échelle, --f, doit être égale à :

var(--m)/(var(--m) - 1)

Pour trois colonnes, nous aurons 3/2 = 1,5 et c'est le facteur d'échelle que j'ai utilisé dans la première démo de cet article car je voulais que l'image soit deux fois plus grande au survol !

La même logique s'applique au calcul de la hauteur et dans le cas où nous voulons contrôler les deux indépendamment, nous devrons considérer deux facteurs d'échelle pour nous assurer que nous avons une largeur et une hauteur spécifiques au survol.

.gallery {
  /* même chose que précédemment */
  --fw: 1.5; /* contrôle le facteur d'échelle pour la largeur */
  --fh: 1.2; /* contrôle le facteur d'échelle pour la hauteur */
  /* même chose qu'avant */
}
.gallery img:hover {
  width: calc(var(--w) * var(--fw));
  height: calc(var(--h) * var(--fh));
}

Vous connaissez maintenant tous les secrets pour créer n'importe quel type de grille d'images avec un effet de survol cool, tout en contrôlant la taille que vous souhaitez à l'aide des calculs que nous venons de voir.

Conclusion

Dans mon dernier article, nous avons créé une grille d'aspect complexe avec quelques lignes de CSS qui mettaient à profit les fonctionnalités de grille implicite et de placement automatique de CSS Grid. Dans cet article, nous nous sommes appuyés sur une astuce de dimensionnement de CSS Grid pour créer une grille fantaisiste dans laquelle les images s'agrandissent au survol de l'écran, entraînant l'ajustement de la grille en conséquence. Tout cela avec un code simplifié et facile à ajuster à l'aide de variables CSS !

Dans le prochain article, nous allons jouer avec les formes ! Nous allons combiner la grille CSS avec mask et clip-path pour obtenir une grille d'images originale.

Vous n'utilisez peut-être pas (ou plus) le XHTML, mais lorsque vous écrivez du HTML, vous êtes peut-être plus influencé par le XHTML que vous ne le pensez. Vous écrivez très probablement du HTML à la manière de XHTML.

Qu'est-ce que la façon XHTML d'écrire du HTML, et qu'est-ce que la façon HTML d'écrire du HTML ? Voyons cela.

HTML, XHTML, HTML

Dans les années 1990, il y avait le HTML. Dans les années 2000, il y a eu le XHTML. Puis, dans les années 2010, nous sommes revenus au HTML. C'est une histoire simple...

Les dates approximatives des spécifications sont également révélatrices : HTML "1" 1992, HTML 2.0 1995, HTML 3.2 1997, HTML 4.01 1999 ; XHTML 1.0 2000, XHTML 1.1 2001 ; "HTML5" 2007.

Le XHTML est devenu populaire lorsque tout le monde croyait que le XML et ses dérivés étaient l'avenir. "XML tout court". Pour le HTML, cela a eu un effet profond et durable : celui de nous apprendre à l'écrire à la façon XHTML.

La façon XHTML d'écrire le HTML

La méthode XHTML est bien documentée, car XHTML 1.0 la décrit en détail dans sa section "Différences avec HTML 4" :

• Les documents doivent être bien formés.
• Les noms des éléments et des attributs doivent être en minuscules.
• Pour les éléments non vides, les balises de fin sont obligatoires.
• Les valeurs des attributs doivent toujours être citées.
• La minimisation des attributs n'est pas prise en charge.
• Les éléments vides doivent être fermés.
• Le traitement des espaces blancs dans les valeurs d'attributs est effectué conformément à XML.
• Les éléments de script et de style doivent comporter des sections CDATA.
• Les exclusions SGML ne sont pas autorisées.
• Les éléments ayant des attributs id et name, comme a, applet, form, frame, iframe, img et map, ne doivent utiliser que id.
• Les attributs ayant des ensembles de valeurs prédéfinies sont sensibles à la casse.
• Les références aux entités comme les valeurs hexadécimales doivent être en minuscules.

Cela vous semble-t-il familier ? À l'exception du balisage du contenu CDATA, ainsi que du traitement des exclusions SGML, vous suivez probablement toutes ces règles. Toutes ces règles.

Bien que le XHTML soit mort, nombre de ces règles n'ont jamais été remises en question. Certaines ont même été élevées au rang de "bonnes pratiques" pour le HTML.

C'est la façon XHTML d'écrire du HTML, et son impact durable sur le domaine.

La façon d'écrire du HTML

Une façon de nous ramener en arrière est de reformuler négativement les règles imposées par le XHTML. Faisons cela (sans la partie SGML, car HTML n'est plus basé sur SGML) :

• Les documents peuvent ne pas être bien formés.
• Les noms des éléments et des attributs peuvent ne pas être en minuscules.
• Pour les éléments non vides, les balises de fin ne sont pas toujours nécessaires.
• Les valeurs des attributs ne sont pas toujours citées.
• La minimisation des attributs est prise en charge.
• Les éléments vides n'ont pas besoin d'être fermés.
• Le traitement des espaces blancs dans les valeurs d'attributs n'est pas réalisé conforment à XML.
• Les éléments de script et de style n'ont pas besoin de sections CDATA.
• Les éléments ayant des attributs id et name ne peuvent pas utiliser uniquement id.
• Les attributs dont les valeurs sont prédéfinies ne sont pas sensibles à la casse.
• Les références aux entités comme les valeurs hexadécimales peuvent ne pas être uniquement en minuscules.

Supprimons les points ésotériques et ceux qui ne semblent pas pertinents. Il s'agit de la gestion des espaces blancs XML, des sections CDATA, du doublement des valeurs des attributs de nom, de la casse des ensembles de valeurs prédéfinis et des références d'entités en hexadécimal :

• Les documents peuvent ne pas être bien formés.
• Les noms des éléments et des attributs peuvent ne pas être en minuscules.
• Pour les éléments non vides, les balises de fin ne sont pas toujours requises.
• Les valeurs des attributs ne sont pas toujours citées.
• La minimisation des attributs est prise en charge.
• Les éléments vides n'ont pas besoin d'être fermés.

Si l'on fait abstraction de ces règles, on a beaucoup moins l'impression de travailler avec du XML, mais plutôt avec du HTML. Mais nous n'avons pas encore terminé.

"Les documents peuvent ne pas être bien formés" semble suggèrer qu'il serait acceptable que le code HTML soit invalide. Il était tout à fait cohérent que XHTML soit pointilleux sur la conformité de la forme en raison de sa gestion stricte des erreurs (par XML). Mais même si les documents HTML fonctionnent encore lorsqu'ils contiennent de graves problèmes de syntaxe et de conformité, il n'est pas utile, ni pour le professionnel ni pour notre domaine d'user et d'abuser de cette résilience. (J'ai déjà plaidé cette cause dans mon article "In Critical Defense of Frontend Development".

La façon HTML ne suggére donc pas que "les documents peuvent ne pas être bien formés". Il devrait également être clair que non seulement les balises de fin, mais aussi celles de début ne sont pas toujours nécessaires. Si nous reformulons et réorganisons, voici l'essentiel :

• Les balises de début et de fin ne sont pas toujours nécessaires.
• Les éléments vides n'ont pas besoin d'être fermés.
• Les noms des éléments et des attributs peuvent être en minuscules ou en majuscules.
• Les valeurs des attributs ne sont pas toujours entre guillemets.
• La minimisation des attributs est prise en charge.

Exemples

Comment cela se présente-t-il en pratique ? Pour les balises de début et de fin, sachez que de nombreuses balises sont facultatives. Un paragraphe et une liste, par exemple, s'écrivent comme ceci en XHTML :

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p>
<ul>
  <li>Praesent augue nisl</li>
  <li>Lobortis nec bibendum ut</li>
  <li>Dictum ac quam</li>
</ul>

En HTML, vous pouvez l'écrire avec ce code (qui est parfaitement valide) :

<p>Lorem ipsum dolor sit amet, consectetur adipiscing elit.
<ul>
  <li>Praesent augue nisl
  <li>Lobortis nec bibendum ut
  <li>Dictum ac quam
</ul>

Les développeurs ont également appris à écrire les éléments vides comme ceci : <br />. C'est encore une chose que le XHTML a apporté au HTML, mais la barre oblique n'ayant aucun effet sur les éléments vides, vous n'avez besoin que de ceci : <br>.

En HTML vous pouvez tout écrire en majuscules :

<A HREF="https://css-tricks.com/">CSS-Tricks</A>

Bon, évidemment, on dirait que vous criez et vous n'aimerez sans doute pas cela, mais enfin il n'est pas interdit de l'écrire comme ça.

Lorsque vous voulez condenser ce lien, le HTML vous offre la possibilité de laisser de côté certains guillemets :

<A HREF=https://css-tricks.com/>CSS-Tricks</A>

Note : En règle générale, lorsque la valeur de l'attribut ne contient pas d'espace ou de signe égal, il est possible de supprimer les guillemets.

Enfin, le HTML-HTML - et non le XHTML-HTML - permet également de minimiser les attributs. C'est-à-dire qu'au lieu de marquer un élément input comme requis et en lecture seule, comme ceci :

<input type="text" required="required" readonly="readonly" />

Vous pouvez minimiser les attributs :

<input type="text" required readonly />

Si vous profitez non seulement du fait que les guillemets ne sont pas nécessaires, mais aussi du fait que le texte est la valeur par défaut de l'attribut type ici (il existe d'autres combinaisons attribut-valeur inutiles), vous obtenez un exemple qui montre le HTML dans toute sa beauté minimale :

<input required readonly />

Écrire du HTML, à la manière du HTML

Ce qui précède n'est pas une représentation de ce qu'était le HTML dans les années 90. À l'époque, le HTML était chargé d'éléments <table> pour la mise en page, rempli de code de présentation, largement invalide (comme c'est encore le cas aujourd'hui), et la compatibilité des agents utilisateurs était très variable. Pourtant, c'est l'essence même de ce que nous aurions voulu conserver si XML et XHTML n'étaient pas arrivés.

Si vous êtes ouvert à une suggestion de ce à quoi pourrait ressembler une manière plus complète et contemporaine d'écrire le HTML, j'en ai une ! (Le HTML étant mon principal domaine d'intérêt, je complète ce texte par des liens vers certains de mes articles).

1. Respectez la syntaxe et la sémantique.
   • Validez votre HTML, et n'envoyez que du HTML valide, utilisez le validateur du W3C
2. Utilisez les options que vous offre le HTML, du moment que vous le faites de manière cohérente.
   • N'oubliez pas que les noms des éléments et des attributs peuvent être en minuscules ou en majuscules.
3. Limitez l'utilisation du HTML au strict minimum
   • Rappelez-vous que le balisage de présentation et de comportement doit être traité par CSS et JavaScript.
   • Rappelez-vous que les balises de début et de fin ne sont pas toujours nécessaires.
   • Rappelez-vous que les éléments vides n'ont pas besoin d'être fermés.
   • N'oubliez pas que certains attributs ont des valeurs par défaut qui permettent d'omettre ces paires attribut-valeur.
   • N'oubliez pas que les valeurs des attributs n'ont pas toujours besoin d'être entre guillemets.
   • N'oubliez pas que la minimisation des attributs est prise en charge.

Ce n'est pas une coïncidence si cela ressemble aux trois règles de base du HTML, si cela fonctionne selon le principe qu'un poids réduit de fichier conduit également à des sites plus rapides, et si cela suit l'école du développement web minimal. Rien de tout cela n'est nouveau - notre domaine pourrait simplement décider de le redécouvrir. Des outils sont également disponibles : html-minifier est probablement le plus connu et le plus à même de gérer toutes les optimisations HTML.

Vous avez appris le HTML à la manière du XHTML. HTML n'est pas XHTML. Redécouvrez le HTML et participez à l'élaboration d'une nouvelle méthode moderne d'écriture du HTML, qui reconnaît le XML sans en faire un dogme intangible.

Au début de cette année, j'ai auto-publié un ebook intitulé Understanding JavaScript Promises (téléchargeable gratuitement). Je n'avais pas l'intention d'en faire un livre imprimé, mais pas mal de personnes m'ayant contacté pour me demander une version imprimée, j'ai décidé de l'auto-publier également. Je me disais qu'il ne serait pas trop compliqué d'utiliser HTML et CSS pour générer un PDF et l'envoyer à l'imprimeur. Ce que je n'avais pas encore réalisé, c'est que je n'avais pas de solution pour gérer une partie importante d'un livre imprimé : la table des matières.

La composition d'une table des matières

À la base, une table des matières est assez simple. Chaque ligne représente une partie d'un livre ou d'une page Web et indique où vous pouvez trouver ce contenu. En général, les lignes contiennent trois parties :

1. Le titre du chapitre ou de la section
2. Des amorces (c'est-à-dire des points, des tirets ou des lignes) qui relient visuellement le titre au numéro de page.
3. Le numéro de page

On peut facilement générer une table des matières à l'aide d'outils de traitement de texte comme Microsoft Word ou Google Docs, mais comme mon contenu était en format Markdown, puis transformé en HTML, ce n'était pas une bonne option pour moi. Je voulais quelque chose d'automatisé qui fonctionne avec HTML pour générer la table des matières dans un format adapté à l'impression. Je voulais également que chaque ligne soit un lien afin de pouvoir l'utiliser dans les pages Web et les PDF pour naviguer dans le document. Je voulais aussi que le titre et le numéro de page soient précédés de points.

J'ai donc commencé à faire des recherches.

Je suis tombé sur deux excellents articles de blog sur la création d'une table des matières avec HTML et CSS. Le premier, intitulé "Build a Table of Contents from your HTML", est signé Julie Blanc. Julie a travaillé sur PagedJS, un polyfill pour les fonctionnalités de médias paginés manquantes dans les navigateurs Web qui formate correctement les documents pour l'impression. J'ai commencé par l'exemple de Julie, mais j'ai trouvé qu'il ne fonctionnait pas vraiment pour moi. J'ai ensuite trouvé le billet de Christoph Grabo intitulé "Responsive TOC leader lines with CSS", qui présentait le concept d'utilisation de CSS Grid (par opposition à l'approche basée sur les float de Julie) pour faciliter l'alignement. Une fois de plus, cependant, son approche ne correspondait pas tout à fait à mes besoins.

Mais après avoir lu ces deux articles, j'ai eu le sentiment d'avoir une compréhension suffisante des problèmes de mise en page pour me lancer dans mon propre projet. J'ai utilisé des éléments des deux articles du blog et j'ai ajouté quelques nouveaux concepts HTML et CSS à mon approche pour arriver à un résultat qui me convient.

Choix du balisage

Lorsque j'ai décidé du balisage correct d'une table des matières, j'ai surtout pensé à la sémantique correcte. Fondamentalement, une table des matières consiste à associer un titre (chapitre ou sous-section) à un numéro de page, presque comme une paire clé-valeur. Cela m'a conduit à deux options :

La première option consiste à utiliser un tableau (<table>) avec une colonne pour le titre et une colonne pour la page. Ensuite, il y a l'élément liste de définition (<dl>), souvent inutilisé et oublié. Il fait également office de carte clé-valeur. Ainsi, une fois encore, la relation entre le titre et le numéro de page serait évidente.

Ces deux options semblaient bonnes jusqu'à ce que je me rende compte qu'elles ne fonctionnent vraiment que pour les tables des matières à un seul niveau, c'est-à-dire uniquement si je voulais avoir une table des matières contenant uniquement les noms des chapitres. En revanche, si je voulais afficher les sous-sections dans la table des matières, je n'avais pas de bonnes options. Les éléments de tableau ne sont pas très adaptés aux données hiérarchiques et, bien que les listes de définitions puissent techniquement être imbriquées, la sémantique ne semblait pas correcte. Je suis donc retourné à la planche à dessin.

J'ai décidé de m'inspirer de l'approche de Julie et d'utiliser une liste ; cependant, j'ai opté pour une liste ordonnée (<ol>) au lieu d'une liste non ordonnée (<ul>). Je pense qu'une liste ordonnée est plus appropriée dans ce cas. Une table des matières représente une liste de chapitres et de sous-titres dans l'ordre dans lequel ils apparaissent dans le contenu. L'ordre a de l'importance et ne doit pas se perdre dans le balisage.

Malheureusement, l'utilisation d'une liste ordonnée implique la perte de la relation sémantique entre le titre et le numéro de page. L'étape suivante consistait donc à rétablir cette relation dans chaque élément de la liste. Le moyen le plus simple de résoudre ce problème est d'insérer le mot "page" avant le numéro de page. De cette façon, la relation entre le numéro et le texte est claire, même sans autre distinction visuelle.

Voici un squelette HTML simple qui a servi de base à mon balisage :

<ol class="toc-list">
  <li>
    <a href="#link_to_heading">
      <span class="title">Chapître ou titres de sous-sections</span>
      <span class="page">Page 1</span>
    </a>
    <ol>
      <!-- sous-sections -->
    </ol>
  </li>
</ol>

Application de styles à la table des matières

Une fois que j'ai établi le balisage que je prévoyais d'utiliser, l'étape suivante consistait à appliquer certains styles.

Tout d'abord, j'ai supprimé les numéros générés automatiquement. Vous pouvez choisir de conserver les numéros générés automatiquement dans votre propre projet si vous le souhaitez, mais il est fréquent que les livres aient des avant et après-mots non numérotés inclus dans la liste des chapitres, ce qui rend les numéros générés automatiquement incorrects.

Pour mon cas, je remplirais les numéros de chapitre manuellement, puis j'ajusterais la mise en page de façon à ce que la liste de premier niveau n'ait pas de remplissage (ce qui l'aligne sur les paragraphes) et que chaque liste intégrée soit indentée de deux espaces. J'ai choisi d'utiliser une valeur de remplissage de 2 ch parce que je n'étais pas encore tout à fait sûr de la police que j'allais utiliser. L'unité de longueur ch permet au remplissage d'être relatif à la largeur d'un caractère - quelle que soit la police utilisée - plutôt qu'à une taille absolue en pixels qui pourrait donner un aspect incohérent.

Voici le CSS que j'ai obtenu :

.toc-list,
.toc-list ol {
  list-style-type: none;
}
.toc-list {
  padding: 0;
}
.toc-list ol {
  padding-inline-start: 2ch;
}

Sara Soueidan m'a fait remarquer que les navigateurs WebKit suppriment la sémantique des listes lorsque list-style-type est none. J'ai donc dû ajouter role="list" dans le HTML pour la préserver :

<ol class="toc-list" role="list">
  <li>
    <a href="#link_to_heading">
      <span class="title">Chapître ou titres de sous-sections</span>
      <span class="page">Page 1</span>
    </a>
    <ol role="list">
      <!-- sous-sections -->
    </ol>
  </li>
</ol>

voirTable of Contents - Startde Nicholas C. Zakas dansCodePen

Stylisation du titre et du numéro de page

La liste étant stylisée à mon goût, il était temps de passer au style d'un élément individuel de la liste. Pour chaque élément de la table des matières, le titre et le numéro de page doivent être sur la même ligne, avec le titre à gauche et le numéro de page aligné à droite.

Vous vous dites peut-être : "Pas de problème, c'est à ça que sert le flexbox !" Vous n'avez pas tort ! Flexbox permet en effet d'obtenir un alignement correct du titre et de la page. Mais il y a quelques problèmes d'alignement délicats lorsque les leaders sont ajoutés, j'ai donc opté pour l'approche de Christoph qui utilise une grille, ce qui est un bonus car cela aide aussi avec les titres multilignes. Voici le CSS pour un article individuel :

.toc-list li > a {
  text-decoration: none;
  display: grid;
  grid-template-columns: auto max-content;
  align-items: end;
}
.toc-list li > a > .page {
  text-align: right;
}

La grille comporte deux colonnes, dont la première est automatiquement dimensionnée pour remplir toute la largeur du conteneur, moins la deuxième colonne, qui est dimensionnée au contenu maximal. Le numéro de page est aligné sur la droite, comme il est de coutume dans une table des matières.

La seule autre modification que j'ai apportée à ce stade a été de masquer le texte "Page". Ce texte est utile pour les lecteurs d'écran, mais inutile sur le plan visuel. J'ai donc utilisé une classe traditionnelle de type "visually-hidden" pour le masquer :

.visually-hidden {
  clip: rect(0 0 0 0);
  clip-path: inset(100%);
  height: 1px;
  overflow: hidden;
  position: absolute;
  width: 1px;
  white-space: nowrap;
}

Et, bien entendu, le HTML doit être mis à jour pour utiliser cette classe :

<ol class="toc-list" role="list">
  <li>
    <a href="#link_to_heading">
      <span class="title">Chapître ou titres de sous-sections</span>
      <span class="page"
        ><span class="visually-hidden">Page</span> 1</span
      >
    </a>
    <ol role="list">
      <!-- sous-sections -->
    </ol>
  </li>
</ol>

Cette base étant posée, je suis passé à la question des lignes pointillées entre le titre et la page.

voirTable of Contents - Étape 2de Nicholas C. Zakas dansCodePen

Création de lignes pointillées

Les lignes pointillées sont si courantes dans les médias imprimés que vous vous demandez peut-être pourquoi le CSS ne les prend pas déjà en charge. La réponse est : c'est le cas. Enfin, plus ou moins...

Il existe en fait une fonction leader() définie dans la spécification CSS Generated Content for Paged Media. Toutefois, comme c'est le cas pour la plupart des spécifications relatives aux médias paginés, cette fonction n'est implémentée dans aucun navigateur, ce qui l'exclut de toute option (du moins au moment où j'écris ces lignes). Elle n'est même pas répertoriée sur caniuse.com, sans doute parce que personne ne l'a implémentée et qu'il n'y a aucun plan ou signe indiquant qu'ils le feront.

Heureusement, Julie et Christoph ont déjà abordé ce problème dans leurs articles respectifs. Pour insérer les lignes pointillées, ils ont tous deux utilisé un pseudo-élément ::after dont la propriété de contenu est définie comme une très longue chaîne de points, comme ceci :

.toc-list li > a > .title {
  position: relative;
  overflow: hidden;
}
.toc-list li > a .title::after {
  position: absolute;
  padding-left: 0.25ch;
  content: ' . . . . . . . . . . . . . . . . . . . '
    '. . . . . . . . . . . . . . . . . . . . . . . '
    '. . . . . . . . . . . . . . . . . . . . . . . '
    '. . . . . . . . . . . . . . . . . . . . . . . '
    '. . . . . . . . . . . . . . . . . . . . . . . '
    '. . . . . . . . . . . . . . . . . . . . . . . '
    '. . . . . . . . . . . . . . . . . . . . . . . ';
  text-align: right;
}

Le pseudo-élément ::after est placé dans une position absolue pour le sortir du flux de la page et éviter qu'il ne revienne à la ligne. Le texte est aligné sur la droite parce que nous voulons que les derniers points de chaque ligne soient alignés sur le numéro en fin de ligne. (Nous reviendrons plus tard sur les complexités de cette question.) L'élément .title est configuré pour avoir une position relative afin que le pseudo-élément ::after ne sorte pas de sa boîte. Pendant ce temps, le débordement est masqué pour que tous ces points supplémentaires soient invisibles. Le résultat est une jolie table des matières avec des lignes pointillées.

Cependant, il y a encore autre chose à prendre en considération.

Sara m'a également fait remarquer que tous ces points sont considérés comme du texte par les lecteurs d'écran. Et du coup, qu'est-ce qu'on entend ? "Introduction point point point point..." jusqu'à ce que tous les points soient annoncés. C'est une expérience terrible pour les utilisateurs de lecteurs d'écran.

La solution consiste à insérer un élément supplémentaire dont l'aria-hidden est réglé sur true, puis à utiliser cet élément pour insérer les points. Ainsi, le HTML devient :

<ol class="toc-list" role="list">
  <li>
    <a href="#link_to_heading">
      <span class="title"
        >Chapître ou titres de sous-sections<span
          class="leaders"
          aria-hidden="true"
        ></span
      ></span>
      <span class="page"
        ><span class="visually-hidden">Page</span> 1</span
      >
    </a>
    <ol role="list">
      <!-- sous-sections -->
    </ol>
  </li>
</ol>

Et le CSS devient :

.toc-list li > a > .title {
  position: relative;
  overflow: hidden;
}
.toc-list li > a .leaders::after {
  position: absolute;
  padding-left: 0.25ch;
  content: ' . . . . . . . . . . . . . . . . . . . '
    '. . . . . . . . . . . . . . . . . . . . . . . '
    '. . . . . . . . . . . . . . . . . . . . . . . '
    '. . . . . . . . . . . . . . . . . . . . . . . '
    '. . . . . . . . . . . . . . . . . . . . . . . '
    '. . . . . . . . . . . . . . . . . . . . . . . '
    '. . . . . . . . . . . . . . . . . . . . . . . ';
  text-align: right;
}

Désormais, les lecteurs d'écran ignoreront les points et épargneront aux utilisateurs la frustration d'entendre l'annonce de plusieurs points.

voirTable of Contents - Étape 3de Nicholas C. Zakas dansCodePen

Touches finales

À ce stade, le composant table des matières est plutôt bien conçu, mais il pourrait bénéficier de quelques petites retouches. Pour commencer, la plupart des livres décalent visuellement les titres des chapitres de ceux des sous-sections. J'ai donc mis les éléments de premier niveau en gras et introduit une marge pour séparer les sous-sections des chapitres qui suivent :

.toc-list > li > a {
  font-weight: bold;
  margin-block-start: 1em;
}

Ensuite, je voulais nettoyer l'alignement des numéros de page. Tout se passait bien lorsque j'utilisais une police à largeur fixe, mais pour les polices à largeur variable, les points de repère peuvent finir par former un motif en zigzag lorsqu'ils s'adaptent à la largeur d'un numéro de page. Par exemple, les numéros de page comportant un 1 sont plus étroits que les autres, ce qui entraîne un désalignement des points d'amorce par rapport aux points des lignes précédentes ou suivantes.

Pour résoudre ce problème, j'ai réglé font-variant-numeric sur tabular-nums afin que tous les chiffres soient traités avec la même largeur. En fixant également la largeur minimale à 2ch, je me suis assuré que tous les chiffres à un ou deux chiffres étaient parfaitement alignés. (Si votre projet compte plus de 100 pages, il est préférable de fixer cette valeur à 3ch). Voici le CSS final pour le numéro de page :

.toc-list li > a > .page {
  min-width: 2ch;
  font-variant-numeric: tabular-nums;
  text-align: right;
}

Et voilà, la table des matières est complète !

voirTable of Contents - Finalde Nicholas C. Zakas dansCodePen

Conclusion

La création d'une table des matières avec rien d'autre que du HTML et du CSS a été un défi plus important que prévu, mais je suis très satisfait du résultat. Non seulement cette approche est suffisamment souple pour s'adapter aux chapitres et aux sous-sections, mais elle permet de gérer les sous-sous-sections sans mettre à jour le CSS. L'approche globale fonctionne sur les pages Web où vous souhaitez créer des liens vers les différents emplacements du contenu, ainsi que sur les PDF où vous souhaitez que la table des matières renvoie à différentes pages. Et bien sûr, elle est également très belle à l'impression si vous souhaitez l'utiliser dans une brochure ou un livre.

Je tiens à remercier Julie Blanc et Christoph Grabo pour leurs excellents articles de blog sur la création d'une table des matières, car ils m'ont été d'une aide précieuse lorsque j'ai commencé. J'aimerais également remercier Sara Soueidan pour ses commentaires sur l'accessibilité pendant que je travaillais sur ce projet.

Supposons que nous ayons ce HTML :

<section>
  <p>Little</p>
  <p>Piggy</p>
  <!-- nous voulons celui-ci -->
</section>

Les deux CSS qui suivent feront exactement la même chose :

p:nth-child(2) {
  color: red;
}

p:nth-of-type(2) {
  color: red;
}

Pourtant, il y aura une différence évidemment.

La définition de notre sélecteur :nth-child, en bon français, signifie sélectionne un élément si :

1. c'est un élément paragraphe
2. c'est le deuxième enfant de son élément parent

La définition de notre sélecteur :nth-of-type, en bon français, signifie :

1. sélectionne le deuxième paragraphe enfant de son élément parent

:nth-of-type est donc, comment dire... moins conditionnel.

Supposons que notre balisage soit maintenant :

<section>
  <h1>Words</h1>
  <p>Little</p>
  <p>Piggy</p>
  <!-- nous voulons celui-ci -->
</section>

Ceci ne fonctionne plus :

p:nth-child(2) {
  color: red;
} /*  incorrect */

Ceci fonctionne :

p:nth-of-type(2) {
  color: red;
} /* fonctionne */

Par "incorrect", je veux dire que le sélecteur :nth-child sélectionne maintenant le mot "Little" au lieu de "Piggy" parce que cet élément est à la fois 1) le second enfant et 2) un élément paragraphe. Par "fonctionne", je veux dire que "Piggy" est toujours sélectionné parce qu'il est le deuxième paragraphe dans cet élément parent.

Si j'ajoutais un titre <h2> après le titre principal <h1>, le sélecteur :nth-child ne sélectionnerait rien du tout puisque maintenant le deuxième enfant n'est plus un paragraphe, et donc le sélecteur ne trouve rien.Le :nth-of-type, lui, fonctionne comme attendu.

Mon sentiment est que :nth-of-type est moins fragile et plus utile en général, même si :nth-child est plus souvent utilisé (semble-t-il). Combien de fois vous êtes-vous demandé "je veux sélectionner le deuxième enfant d'un élément parent s'il se trouve être un paragraphe" ? Parfois, peut-être, mais il est plus probable que vous vouliez "sélectionner le deuxième paragraphe" ou "sélectionner chaque troisième rangée d'un tableau", qui sont des cas où :nth-of-type est un choix plus solide (là encore, de mon point de vue).

J'ai l'impresson que mes moments de "Grrrr... mais pourquoi ce sélecteur :nth-child ne marche pas ?!" viennent du fait que j'ai qualifié le sélecteur avec un tag et que le numéro d'ordre de l'enfant ne correspond pas à ce tag. Par conséquent, lorsque j'utilise :nth-child, je me rends compte qu'il est préférable de spécifier le parent et de laisser :nth-child non qualifié.

dl :nth-child(2) {
} /* est mieux que */
dd:nth-child(2) {
} /* ceci */

Mais bien sûr tout dépend de la situation exacte.

Vous pouvez jouer avec ce super outil de test ! Voir également la page MDN de :last-of-type et la page MDN de :nth-child

Le sélecteur :last-of-type nous permet de cibler la dernière occurrence d'un élément à l'intérieur de son élément parent. Il est défini dans la spécification Selectors Level 4 comme une "pseudo-classe structurelle", c'est à dire qu'il est utilisé pour ajouter un style à un contenu en fonction de sa relation avec son élément parent ou ses éléments frères.

Admettons que nous ayons un article qui comporte un titre, plusieurs paragraphes et une image :

<article>
  <h1>Un Titre</h1>
  <p>Paragraphe 1</p>
  <p>Paragraphe 2</p>
  <p>Paragraphe 3</p>
  <img src="..." />
</article>

Nous voulons que le dernier paragraphe soit affiché en plus petit, pour apparaître comme une conclusion (comme une note du rédacteur). Plutôt que de l'associer à une classe, nous pouvons utiliser :last-of-type pour le sélectionner :

p:last-of-type {
  font-size: 0.75em;
}

:last-of-type fonctionne à peu près comme :nth-of-child mais avec une différence essentielle : il est moins spécifique. Dans l'exemple qui précède, si nous avions utilisé p:nth-last-child(1), il ne se serait rien passé car le paragraphe n'est pas le dernier enfant de son élément parent. C'est là qu'apparaît la puissance de :last-of-type : il cible un type particulier d'élément dans un arrangement spécifique, en relation avec des enfants similaires, plutôt qu'avec tos les enfants.

L'exemple plus complexe qui suit montre l'utilisation de :last-of-type et d'une pseudo-classe qui lui ressemble, :first-of-type.

voir:first-of-type and :last-of-typede Sara Cope dansCodePen

Voir également la page de MDN

Beaucoup de gens me demandent de leur recommander des tutoriels sur divers aspects de CSS ou me demandent comment apprendre CSS. Je vois aussi beaucoup de personnes qui ont du mal à comprendre certaines parties de CSS, en raison parfois d'idées dépassées sur le langage. Le langage CSS a considérablement évolué ces dernières années, c'est donc le moment idéal pour rafraîchir nos connaissances. Même si le CSS ne représente qu'une petite partie de votre travail, c'est grâce au CSS que les choses finissent par ressembler à ce que nous voulons à l'écran, et il vaut donc la peine d'être raisonnablement à jour.

Cet article a pour but de présenter les principes fondamentaux de CSS et les ressources à consulter pour approfondir les domaines essentiels du développement CSS moderne. La plupart de ces ressources se trouvent ici même (sur Smashing Magazine), mais j'ai également sélectionné d'autres ressources et des personnes à suivre dans des domaines-clés du CSS. Il ne s'agit pas d'un guide complet pour les débutants, ni d'un guide destiné à couvrir absolument tous les aspects de CSS. Mon objectif est de couvrir l'essentiel du CSS moderne en me concentrant sur quelques domaines qui vous aideront à accéder au reste du langage.

Notions fondamentales du langage

Pour l'essentiel de CSS, vous n'avez pas à vous soucier d'apprendre les propriétés et les valeurs par cœur, vous pourrez les retrouver (NdT : sur MDN par exemple) lorsque vous en aurez besoin. Cependant, il existe certains fondamentaux du langage, sans lesquels vous aurez du mal à vous y retrouver. Il vaut vraiment la peine de consacrer un peu de temps à vous assurer que vous comprenez ces éléments, vous gagnerez du temps et vous éviterez beaucoup de frustration à long terme.

Les sélecteurs, plus qu'une simple classe

Un sélecteur fait ce qu'il est censé faire : il sélectionne une partie de votre document afin que vous puissiez lui appliquer des règles CSS. L'utilisation d'une classe ou l'application d'un style à un élément HTML tel que body, est généralement familière à tous, mais il existe un grand nombre de sélecteurs plus avancés qui peuvent sélectionner des éléments en fonction de leur emplacement dans le document, par exemple parce qu'ils viennent directement après un élément ou que ce sont les rangées impaires d'un tableau.

Les sélecteurs faisant partie de la spécification de niveau 3 (vous avez peut-être déjà entendu parler d'eux sous le nom de sélecteurs de niveau 3) sont très bien pris en charge par les navigateurs. Pour un examen détaillé des différents sélecteurs que vous pouvez utiliser, consultez la référence MDN.

Certains sélecteurs agissent comme si vous aviez appliqué une classe à un élément du document. Par exemple, p:first-child se comporte comme si vous aviez ajouté une classe au premier élément p. Ces sélecteurs sont connus sous le nom de sélecteurs de pseudo-classe.

Les sélecteurs de pseudo-éléments quant à eux agissent comme si un élément était inséré dynamiquement, par exemple ::first-line agit de la même manière que si vous aviez enveloppé la première ligne de texte dans un span. Toutefois, il s'applique à nouveau si la longueur de la ligne change, ce qui ne serait pas le cas si vous insériez l'élément. Ces sélecteurs peuvent être assez complexes. Dans le CodePen ci-dessous, vous trouverez un exemple de pseudo-élément enchaîné avec une pseudo-classe. Nous ciblons le premier élément p avec une pseudo-classe :first-child, puis le sélecteur ::first-line sélectionne la première ligne de cet élément, agissant comme si un span était ajouté autour de cette première ligne afin de la mettre en gras et d'en changer la couleur.

voirfirst-linede rachelandrew dansCodePen

L'héritage et la cascade

La cascade définit la règle qui l'emporte lorsque plusieurs règles peuvent s'appliquer à un élément. Si vous avez déjà été dans une situation où vous ne compreniez pas pourquoi certains CSS ne semblaient pas s'appliquer, il est probable que la cascade en soit responsable. La cascade est étroitement liée à l'héritage, qui définit quelles propriétés sont héritées par les éléments enfants de l'élément auquel elles sont appliquées. Elle est également liée à la spécificité ; les différents sélecteurs ont une spécificité différente qui détermine lequel l'emporte lorsque plusieurs sélecteurs peuvent s'appliquer à un élément.

Remarque : pour bien comprendre toutes ces notions, je vous suggère de lire la section Cascade et héritage dans l'intro à CSS de MDN.

??  La Cascade recommande aussi la lecture de Cascade et priorité des sélecteurs de Laurent Denis dans openweb.

Si vous avez du mal à appliquer un CSS à un élément, les DevTools de votre navigateur sont le meilleur endroit pour commencer vos investigations. Regardez l'exemple ci-dessous dans lequel j'ai un élément h1 ciblé par le sélecteur d'élément h1 et qui rend le titre orange. J'utilise également une classe, qui donne à l'élément h1 la couleur rebeccapurple. La classe est plus spécifique et le h1 est donc violet et non orange. Dans DevTools, vous pouvez voir que le sélecteur d'élément est barré car il ne s'applique pas. Une fois que vous avez constaté que le navigateur reçoit votre CSS (mais que quelque chose d'autre a pris le dessus), vous pouvez commencer à chercher à savoir pourquoi.

voirspécificitéde rachelandrew dansCodePen

Le modèle de boîte

Les CSS sont des boîtes. Tout ce qui est affiché à l'écran a une boîte, et le modèle de boîte décrit la façon dont la taille de cette boîte est calculée, en tenant compte des marges, du padding et des bordures. Le modèle de boîte CSS standard prend la largeur que vous avez donnée à un élément, puis ajoute à cette largeur le padding et la bordure, ce qui signifie que l'espace occupé par l'élément est plus grand que la largeur que vous lui avez donnée.

Plus récemment, nous avons pu choisir d'utiliser un autre modèle de boîte qui utilise la largeur donnée à l'élément comme la largeur de l'élément visible à l'écran. Tout padding ou bordure insère le contenu de la boîte à partir des bords. Cela est beaucoup plus logique pour de nombreuses mises en page.

Dans la démo ci-dessous, j'ai deux boîtes. Elles ont toutes deux une largeur de 200 pixels, une bordure de 5 pixels et un padding de 20 pixels. La première boîte utilise le modèle de boîte standard et occupe donc une largeur totale de 250 pixels. La seconde utilise le modèle de boîte alternatif et a donc une largeur de 200 pixels.

voirmodèle de boîtede rachelandrew dansCodePen

Là encore, les DevTools du navigateur peuvent nous aider à comprendre le modèle de boîte utilisé. Dans l'image ci-dessous, j'utilise Firefox DevTools pour inspecter une boîte utilisant le modèle de boîte content-box par défaut. Les outils m'indiquent qu'il s'agit du modèle de boîte utilisé, et je peux voir le dimensionnement et la façon dont la bordure et le remplissage sont ajoutés à la largeur que j'ai attribuée.

Remarque : avant IE6, Internet Explorer utilisait un autre modèle de boîte, avec un padding et des bordures insérant le contenu en dehors de la largeur donnée. Pendant un certain temps, les navigateurs ont donc utilisé des modèles de boîtes différents ! Lorsque vous rencontrez des problèmes d'interopérabilité aujourd'hui, réjouissez-vous que les choses se soient améliorées et que les navigateurs ne calculent pas la largeur des objets de manière différente.

Vous trouverez une bonne explication du modèle de boîte et du dimensionnement des boîtes dans CSS Tricks, ainsi qu'une explication de la meilleure façon d'utiliser globalement le modèle de boîte alternatif dans votre site.

??  La Cascade recommande aussi la lecture de Contrôler le modèle de boîte d'Ire Aderinokun, et de Box-sizing pour les nuls de Paula Borowska, publiés ici même.

Flux normal

Si vous avez un document dont le contenu est balisé par du HTML et que vous le visualisez dans un navigateur, il sera, avec un peu de chance, lisible. Les titres et les paragraphes commencent sur une nouvelle ligne, les mots s'affichent comme une phrase avec un seul espace blanc entre eux. Les balises de mise en forme, telles que em, n'interrompent pas le flux de la phrase. Ce contenu s'affiche en mode Normal Flow ou Block Flow Layout. Chaque partie du contenu est décrite comme étant "en flux" ; elle connaît le reste du contenu et ne se chevauche donc pas.

Si vous travaillez avec ce comportement plutôt que contre lui, votre vie sera beaucoup plus facile. C'est l'une des raisons pour lesquelles il est très utile de commencer par un document HTML correctement balisé. En effet, grâce au flux normal et aux feuilles de style intégrées des navigateurs qui le respectent, votre contenu commence à être lisible.

Contextes de formatage

Une fois que vous avez un document dont le contenu est en flux normal, vous pouvez souhaiter modifier l'apparence d'une partie de ce contenu. Pour ce faire, vous devez modifier le contexte de mise en forme de l'élément. Par exemple, si vous souhaitez que tous vos paragraphes soient regroupés et ne commencent pas sur une nouvelle ligne, vous pouvez changer l'élément p en display : inline, ce qui le fait passer d'un contexte de bloc à un contexte de mise en forme en ligne.

Les contextes de mise en forme définissent essentiellement un type externe et un type interne. Le type externe contrôle le comportement de l'élément par rapport aux autres éléments de la page, tandis que le type interne contrôle l'apparence des enfants. Ainsi, par exemple, lorsque vous dites display : flex, vous définissez le contexte extérieur comme étant un contexte de formatage de bloc et les enfants comme ayant un contexte de formatage de flex.

Remarque : La dernière version de la spécification d'affichage modifie les valeurs de display pour déclarer explicitement la valeur intérieure et extérieure. Par conséquent, à l'avenir, vous pourrez dire display : block flex ; (block étant la valeur externe et flex la valeur interne).

Pour en savoir plus sur l'affichage, rendez-vous sur MDN.

Être dans ou hors du flux

Les éléments CSS sont décrits comme étant "dans le flux" ou "hors du flux". Les éléments dans le flux sont dotés d'un espace et cet espace est respecté par les autres éléments dans le flux. Si vous sortez un élément du flux, en le faisant flotter ou en le positionnant, l'espace de cet élément ne sera plus respecté par les autres éléments dans le flux.

Cela se remarque surtout avec les éléments positionnés de manière absolue. Si vous donnez à un élément une position : absolute, il est sorti du flux, vous devrez alors vous assurer que vous n'avez pas une situation dans laquelle l'élément hors du flux chevauche et rend illisible une autre partie de votre mise en page.

voirpositionnement absolu hors du fluxde rachelandrew dansCodePen

Quant aux éléments flottants, ils sont également retirés du flux et, même si le contenu qui suit semble s'enrouler autour d'eux, on peut voir en plaçant une couleur de fond sur la boîte des éléments suivants qu'en réalité ils se sont élevés, ont raccourci leurs lignes, et ignorent l'espace utilisé par l'élément flottant.

voirélément flottant hors du fluxde rachelandrew dansCodePen

Vous pouvez en savoir plus sur les éléments en flux et hors flux sur MDN. Ce qu'il faut retenir, c'est que si vous retirez un élément du flux, vous devez gérer vous-même le chevauchement, car les règles habituelles de mise en page du flux de blocs ne s'appliquent plus.

Mise en page

Pendant plus de quinze ans, nous avons fait de la mise en page en CSS sans système de mise en page conçu pour ce travail. Cela a changé. Nous disposons désormais d'un système de mise en page parfaitement adapté, qui comprend la grille (Grid) et le Flexbox, mais aussi la mise en page en colonnes multiples et les anciennes méthodes de mise en page utilisées à bon escient. Si la mise en page CSS est un mystère pour vous, rendez-vous sur le tutoriel MDN Learn Layout, ou lisez mon article Getting Started With CSS Layout dans Smashing Magazine.

N'imaginez pas que des méthodes telles que Grid et Flexbox soient de quelque façon concurrentes. Pour bien utiliser Layout, vous constaterez parfois qu'un composant est meilleur en tant que composant Flexbox et parfois en tant que Grid. À l'occasion, vous voudrez le comportement de flux de colonnes de multicol. Tous ces choix sont valables. Si vous avez l'impression de vous battre contre le comportement d'un élément, c'est en général un très bon signe qu'il vaut sans doute la peine de prendre du recul et d'essayer une approche différente. Nous avons tellement l'habitude de bidouiller les CSS pour leur faire faire ce que nous voulons que nous risquons d'oublier que nous avons pas mal d'autres options à disposition.

La mise en page est mon principal domaine d'expertise et j'ai écrit un certain nombre d'articles dans Smashing Magazine et ailleurs pour essayer d'aider à apprivoiser le nouveau paysage de la mise en page. En plus de l'article sur la mise en page mentionné ci-dessus, j'ai tout une série d'articles sur Flexbox - commencez par Que se passe-t-il quand on crée un Flexbox Flex Container. Dans l'article Grid By Example, je propose toute une série de petits exemples de CSS Grid, ainsi qu'un tutoriel vidéo.

En outre, et surtout pour les designers, jetez un coup d'œil à Jen Simmons et à sa série de vidéos Layout Land.

Alignement

J'ai séparé l'alignement de la mise en page en général car, bien que la plupart d'entre nous aient été initiés à l'alignement dans le cadre de Flexbox, ces propriétés s'appliquent à toutes les méthodes de mise en page et il est utile de les comprendre dans ce contexte plutôt que de penser à "l'alignement Flexbox" ou "l'alignement CSS Grid". Nous disposons d'un ensemble de propriétés d'alignement qui fonctionnent de manière commune dans la mesure du possible ; elles présentent ensuite quelques différences dues au comportement des différentes méthodes de mise en page.

Sur MDN, vous pouvez étudier l'alignement des boîtes et la manière dont il est mis en œuvre pour la grille, Flexbox, Multicol et la disposition en blocs. Dans Smashing Magazine, j'ai un article qui traite spécifiquement de l'alignement dans Flexbox : CSS Flexbox et l'alignement, guide complet.

Dimensionnement

J'ai passé une grande partie de 2018 à parler de la spécification de dimensionnement intrinsèque et extrinsèque, et de la façon dont elle se rapporte à Grid et à Flexbox en particulier. Sur le web, nous sommes habitués à définir le dimensionnement en longueurs ou en pourcentages, car c'est ainsi que nous avons pu réaliser des mises en page de type Grid à l'aide de nombres flottants. Toutefois, les méthodes de mise en page modernes peuvent effectuer une grande partie de la répartition de l'espace à notre place, si nous les laissons faire. Il vaut la peine de comprendre comment Flexbox attribue l'espace (ou comment fonctionne l'unité fr Grid).

Dans Smashing Magazine, j'ai écrit sur le dimensionnement dans la mise en page en général et aussi pour Flexbox dans How Big Is That Flexible Box ?

Conception réactive

Nos nouvelles méthodes de mise en page (Grid et Flexbox) nous permettent souvent d'utiliser moins de media queries qu'avec nos anciennes méthodes, car elles sont flexibles et répondent aux changements de taille des fenêtres ou des composants sans que nous ayons besoin de modifier la largeur des éléments. Cependant, il y aura des endroits où vous voudrez ajouter des breakpoint pour améliorer votre design.

Pour les media queries, en général, consultez mon article Utiliser les media queries pour le Responsive Design en 2018. J'y jette un coup d'œil à ce que les media queries peuvent faire pour nous, et je montre également les nouvelles fonctionnalités à venir pour les media queries dans le niveau 4 de la spécification.

Polices et typographie

Parallèlement à la mise en page, l'utilisation des polices sur le web a subi d'énormes changements l'année dernière. Les polices variables, qui permettent à un seul fichier de police d'avoir des variations illimitées, sont là. Pour avoir un aperçu de ce qu'elles sont et de leur fonctionnement, regardez cet excellent exposé de Mandy Michael : Variable Fonts and the Future of Web Design . Je vous recommande également Dynamic Typography With Modern CSS and Variable Fonts de Jason Pamental.

Pour explorer les polices variables et leurs capacités, il existe une démo amusante de Microsoft ainsi qu'un certain nombre de terrains de jeu pour tester les polices variables - Axis Praxis étant le plus connu (j'aime aussi le Font Playground).

Une fois que vous aurez commencé à travailler avec des polices variables, ce guide sur MDN vous sera d'une grande utilité. Pour apprendre à mettre en œuvre une solution de repli pour les navigateurs qui ne prennent pas en charge les polices variables, lisez Implementing a Variable Font With Fallback Web Fonts d'Oliver Schöndorfer. L'éditeur de polices de Firefox DevTools permet également de travailler avec des polices variables.

Transformations et animations

Les transformations et les animations CSS sont des sujets que je consulte en fonction de mes besoins. Je n'ai pas souvent besoin de les utiliser, et la syntaxe semble me sortir de la tête entre deux utilisations. Heureusement, la référence sur MDN m'aide et je suggère de commencer par les guides sur l'utilisation des transformations CSS et l'utilisation des animations CSS. Zell Liew a également rédigé un article intéressant qui explique en détail les transitions CSS.

Pour avoir une idée de tout ce qu'on peut faire, jetez un coup d'œil au site d'Animista.

L'une des choses qui peut prêter à confusion avec les animations, c'est l'approche à adopter. En plus de ce qui est pris en charge par CSS, vous pouvez avoir besoin d'impliquer JavaScript, SVG ou l'API d'animation Web, et tous ces éléments ont tendance à être mis dans le même panier. Dans son exposé intitulé "Choose Your Animation Adventure" enregistré à An Event Apart, Val Head explique les différentes options.

Utilisez les antisèches comme un aide-mémoire, pas comme un outil d'apprentissage !

Lorsque je mentionne des ressources relatives à Grid ou Flexbox, je reçois souvent des réponses indiquant qu'il est impossible d'utiliser Flexbox sans une antisèche. Je n'ai aucun problème avec les antisèches en tant qu'aide-mémoire pour consulter la syntaxe, et j'en ai publié quelques-unes moi-même. Le problème, si l'on s'en remet entièrement à elles, c'est que l'on risque de ne pas comprendre pourquoi les choses fonctionnent en copiant la syntaxe. Ensuite, lorsque vous rencontrez un cas où cette propriété semble se comporter différemment, cette incohérence apparente semble déconcertante, ou un défaut du langage.

Si vous vous trouvez dans une situation où CSS semble faire quelque chose de très étrange, demandez-vous pourquoi. Créez un scénario de test réduit qui met en évidence le problème, demandez à quelqu'un qui connaît mieux la spécification. La plupart des problèmes CSS sur lesquels on me pose des questions sont dus au fait que la personne concernée pense qu'une propriété fonctionne d'une manière différente de celle qu'elle utilise en réalité. C'est la raison pour laquelle je parle beaucoup de choses comme l'alignement et le dimensionnement, car c'est là que réside souvent cette confusion.

Oui, il y a des choses étranges dans CSS. C'est un langage qui a évolué au fil des ans, et il y a des choses que nous ne pouvons pas changer - jusqu'à ce que nous inventions une machine à remonter le temps. Cependant, une fois que vous aurez acquis quelques notions de base et que vous comprendrez pourquoi les choses se comportent comme elles le font, vous aurez beaucoup plus de facilité avec les notions plus pointues.

??  NdT : La Cascade a traduit de nombreux articles de Rachel Andrew, dont vous trouverez la liste dans la page de l'auteur. Par ailleurs, les pages de tags sont enrichies de nombreuses ressources (autrefois listées dans la page Ressources de La Cascade), voyez par exemple la page CSS ou la page Flexbox.

Nous allons voir différentes façons de contrôler (ou pas) le flux du texte sur une page Web. CSS nous offre de nombreux outils pour assurer ce flux — retour à la ligne, coupure de mots — mais nous verrons également plusieurs astuces utilisant HTML et les caractères spéciaux.

Protection de la mise en page

Normalement, le texte retourne à la ligne dès que l'opportunité se présente, c'est-à-dire aux endroits où l'on s'attend à ce que le texte s'interrompe naturellement, entre les mots ou après un trait d'union. Mais on a parfois affaire à de longues portions de texte qui ne présentent pas de possibilités de retour à la ligne, comme des mots très longs ou des URL. Cela peut entraîner toutes sortes de problèmes de mise en page. Par exemple, le texte peut déborder de son conteneur ou forcer le conteneur à devenir trop large et pousser des éléments hors de leur place.

Un bon codage défensif consiste à anticiper les problèmes liés à l'absence de rupture explicite du texte, et CSS nous fournit quelques outils à cet effet.

Faire en sorte que le texte retourne à la ligne

En plaçant overflow-wrap : break-word sur un élément, le texte pourra être interrompu au milieu du mot si nécessaire. L'algorithme essaiera d'abord de garder un mot intact en le déplaçant à la ligne suivante, mais il coupera le mot s'il n'y a toujours pas assez de place.

voiroverflow-wrap: break-wordde Will Boyd dansCodePen

Il y a également overflow-wrap : anywhere, qui coupe les mots de la même manière. La différence réside dans la façon dont il affecte le calcul de la taille du contenu minimal de l'élément sur lequel il se trouve. L'effet est assez évident quand on fixe la largeur à min-content :

.top {
  width: min-content;
  overflow-wrap: break-word;
}
.bottom {
  width: min-content;
  overflow-wrap: anywhere;
}

voiroverflow-wrap + min-contentde Will Boyd dansCodePen

Le premier élément avec overflow-wrap : break-word calcule le contenu minimal comme si aucun mot n'était coupé, de sorte que sa largeur devient la largeur du mot le plus long. L'élément du bas avec overflow-wrap : anywhere calcule le contenu minimal avec toutes les coupures qu'il peut créer. Vu qu'une coupure peut se produire n'importe où, le contenu minimal correspond à la largeur d'un seul caractère.

N'oubliez pas que ce comportement ne se produit que lorsque min-content est impliqué. Si nous avions donné une valeur fixe à la largeur, nous verrions le même résultat de coupure de mots dans les deux cas de figure.

Couper les mots sans pitié

Une autre option pour créer une césure est word-break: break-all. Celle-ci n'essaiera même pas de garder les mots entiers — elle les coupera immédiatement. Voici ce que ça donne :

voirword-break: break-allde Will Boyd dansCodePen

Remarquez comment le mot long n'est pas déplacé à la ligne suivante, comme il l'aurait été en utilisant overflow. Remarquez aussi comment "words" est coupé, même s'il aurait pu être placé sur la ligne suivante.

word-break : break-all n'a aucun problème à couper les mots, mais il reste toujours prudent avec la ponctuation. Par exemple, il évitera de commencer une ligne avec le point de la fin d'une phrase. Si vous voulez une rupture vraiment impitoyable, même avec la ponctuation, utilisez line-break : anywhere.

voirword-break: break-all vs line-break: anywherede Will Boyd dansCodePen

Vous avez vu comment word-break : break-all déplace le "k" vers le bas pour éviter de commencer la deuxième ligne avec "." ? Mais line-break : anywhere , lui, s'en moque.

Ponctuation excessive

Voyons comment les propriétés CSS que nous avons abordées jusqu'à présent traitent les signes de ponctuation excessivement longs.

voirPonctuation excessivede Will Boyd dansCodePen

overflow-wrap : break-word et line-break : anywhere sont capables de contenir les choses, mais il y a ensuite word-break : break-all qui est de nouveau bizarre avec la ponctuation — cette fois-ci, le résultat est un texte qui déborde.

C'est une chose à garder à l'esprit. Si vous ne voulez absolument pas que le texte déborde, sachez que word-break : break-all n'empêchera pas la ponctuation de dépasser.

Spécifier où les mots peuvent être coupés

Pour plus de contrôle, vous pouvez insérer manuellement des possibilités de coupure de mots dans votre texte avec <wbr>. Vous pouvez également utiliser un "espace de largeur nulle", fourni par l'entité HTML ​ (oui, il faut des majuscules comme vous le voyez !).

Voyons ces éléments en action avec une longue URL qui ne serait normalement pas retournée à la ligne, en insérant des césures entre les segments.

  <!-- normal -->
  <p>https://subdomain.somewhere.co.uk</p>
  <!-- <wbr> -->
  <p>https://subdomain<wbr>.somewhere<wbr>.co<wbr>.uk</p>
  <!-- &ZeroWidthSpace; -->
  <p>https://subdomain&ZeroWidthSpace;.somewhere&ZeroWidthSpace;.co&ZeroWidthSpace;.uk</p>

voirManual Word Break Opportunitiesde Will Boyd dansCodePen

Trait d'union automatique

Vous pouvez demander au navigateur de couper les mots avec un trait d'union lorsque nécessaire en utilisant l'option hyphens: auto. Les règles de césure sont déterminées par la langue. Vous devez donc indiquer au navigateur la langue à utiliser. Pour ce faire, vous devez spécifier l'attribut lang dans le HTML, soit directement dans l'élément concerné, soit dans la balise <html>.

<p lang="en">This is just a bit of arbitrary text to show hyphenation in action.</p>

  p {
    -webkit-hyphens: auto; /* pour Safari */
    hyphens: auto;
  }

voirhyphens: autode Will Boyd dansCodePen

Trait d'union manuel

Vous pouvez également prendre les choses en main et insérer un "tiret doux" manuellement avec l'entité HTML ­. Il ne sera pas visible, à moins que le navigateur ne décide de l'insérer, auquel cas un trait d'union apparaîtra. Remarquez dans la démo suivante que nous utilisons deux fois l'entité ­ mais qu'elle n'apparaît qu'une seule fois, là où le texte doit effectivement retourner à la ligne.

<p lang="en">Magic? Abraca&shy;dabra? Abraca&shy;dabra!</p>

voirTrait d'union douxde Will Boyd dansCodePen

hyphens doit être réglé sur auto ou manual pour que ­ s'affiche correctement. Par commodité, la valeur par défaut est hyphens : manual, ce qui devrait vous permettre de vous passer de tout CSS supplémentaire (à moins que quelque chose quelque part n'ait déclaré hyphens : none pour une raison quelconque).

Empêcher le texte de revenir à la ligne

Changeons de sujet. Il peut arriver que vous ne souhaitiez pas que le texte retourne librement à la ligne, afin de mieux contrôler la façon dont votre contenu est présenté. Il existe quelques outils pour vous aider.

Le premier est white-space : nowrap. Placez-le sur un élément pour empêcher son texte de revenir à la ligne naturellement.

voirwhite-space: nowrapde Will Boyd dansCodePen

Préformater le texte

Il existe également la fonction white-space : pre, qui permet d'afficher un retour à la ligne du texte tel que vous l'avez saisi dans votre HTML. Prenez garde toutefois, car il conservera également les espaces de votre HTML, donc faites attention à votre formatage. Vous pouvez également utiliser une balise <pre> pour obtenir les mêmes résultats (elle comporte un white-space : pre par défaut).

<!-- le formatage de ce HTML a pour conséquence un espace blanc supplémentaire -->
<p>
  What's worse, ignorance or apathy?
  I don't know and I don't care.
</p>
<!-- un formatage plus serré qui "embrasse" le texte -->
<p>What's worse, ignorance or apathy?
I don't know and I don't care.</p>
<!-- comme ci-dessus, mais avec <pre> -->
<pre>What's worse, ignorance or apathy?
I don't know and I don't care.</pre>

p {
  white-space: pre;
}
pre {
  /* <pre> sets font-family: monospace, but we can undo that */
  font-family: inherit;
}

voirTexte préformatéde Will Boyd dansCodePen

Un retour à la ligne dans un insécable ?

Pour les sauts de ligne, vous pouvez utiliser <br> à l'intérieur d'un élément avec white-space: nowrap ou white-space: pre. Le texte retournera à la ligne.

Mais que se passe-t-il si vous utilisez <wbr> dans un tel élément ? C'est une question piège… parce que les navigateurs ne sont pas d'accord ! Chrome/Edge reconnaîtra le <wbr> et retournera à la ligne potentiellement, mais pas Firefox/Safari.

En ce qui concerne l'espace de largeur nulle ​, les navigateurs sont cohérents. Aucun ne renverra à la ligne avec white-space: nowrap ou white-space: pre.

<p>Darth Vader: Nooooooooooooo<br>oooo!</p>
<p>Darth Vader: Nooooooooooooo<wbr>oooo!</p>
<p>Darth Vader: Nooooooooooooo&ZeroWidthSpace;oooo!</p>

voirwhite-space: nowrap + breaking linesde Will Boyd dansCodePen

Espaces insécables

Parfois, vous souhaiterez peut-être que le texte retourne librement à la ligne, sauf à des endroits très spécifiques. Bonne nouvelle ! Il existe quelques entités HTML spécialisées qui vous permettent de faire exactement cela.

Un "espace insécable" ( ) est souvent utilisé pour conserver un espace entre les mots, mais n'autorise pas de saut de ligne entre eux (ils forment alors un tout insécable).

<p>Something I've noticed is designers don't seem to like orphans.</p>
<p>Something I've noticed is designers don't seem to like&nbsp;orphans.</p>

voirEspaces insécablesde Will Boyd dansCodePen

?? NdT : un exemple courant (et recommandé) d'utilisation de l'espace insécable est l'espace précédant un signe de ponctuation, par exemple un point d'exclamation ! ou le suivant, par exemple : — un tiret cadratin. Nous ne contrôlons pas la largeur des écrans de nos utilisateurs, l'espace insécable évite les signes de ponctuation orphelins en début ou en fin de ligne.

Jointures de mots et traits d'union insécables

Un texte peut retourner naturellement à la ligne même sans espaces, par exemple après un trait d'union à l'intérieur d'un mot. Pour empêcher le retour à la ligne, vous pouvez utiliser ⁠ (sensible à la casse !) qui agit comme un "agrégateur de mots". Pour les traits d'union en particulier, vous pouvez obtenir un "trait d'union insécable" avec ‑ (il n'a pas de joli nom d'entité HTML).

  <p>Turn right here to get on I-85.</p>
  <p>Turn right here to get on I-&NoBreak;85.</p>
  <p>Turn right here to get on I&#8209;85.</p>

voirWord Joiners and Non-Breaking Hyphensde Will Boyd dansCodePen

Texte CJC et mots de rupture

Le texte CJC (chinois/japonais/coréen) se comporte à certains égards différemment du texte non CJC. Certaines propriétés et valeurs CSS peuvent être utilisées pour un contrôle supplémentaire du retour à la ligne du texte CJC spécifiquement.

Le comportement par défaut du navigateur permet de couper des mots dans le texte CJC. Cela signifie que word-break: normal (par défaut) et word-break: break-all vous donneront les mêmes résultats. Cependant, vous pouvez utiliser word-break: keep-all pour empêcher le texte CJC de revenir à la ligne au milieu des mots (le texte non CJC ne sera pas affecté).

Voici un exemple en coréen. Notez comment le mot "자랑스럽게" se coupe ou ne se coupe pas.

voirCJK Text + word-breakde Will Boyd dansCodePen

Attention toutefois, le chinois et le japonais n'utilisent pas d'espaces entre les mots comme le fait le coréen, donc word-break: keep-all peut facilement provoquer un long débordement de texte s'il n'est pas géré autrement.

Texte CJC et règles de saut de ligne

Nous avons parlé de line-break: anywhere tout à l'heure avec du texte non CJC et du fait qu'il n'a aucun problème à couper à la ponctuation. Il en va de même avec le texte CJC.

Voici un exemple en japonais. Notez comment "。" est ou n'est pas autorisé à commencer une ligne.

voirCJK Text + line-breakde Will Boyd dansCodePen

Il existe d'autres valeurs pour line-break qui affectent la façon dont le texte CJC retourne à la ligne : loose, normal et strict. Ces valeurs indiquent au navigateur les règles à utiliser pour décider où insérer des sauts de ligne. Le W3C décrit plusieurs règles et il est également possible pour les navigateurs d'ajouter leurs propres règles.

À mentionner : Débordement d'élément

La propriété CSS overflow n'est pas spécifique au texte, mais est souvent utilisée pour s'assurer que le texte ne s'affiche pas en dehors d'un élément dont la largeur ou la hauteur est délimitée.

.top {
  white-space: nowrap;
  overflow: auto;
}
.bottom {
  white-space: nowrap;
  overflow: hidden;
}

voirElement Overflowde Will Boyd dansCodePen

Comme vous pouvez le voir, une valeur auto permet de faire défiler le contenu (auto n'affiche les barres de défilement qu'en cas de besoin, scroll les affiche toujours). Une valeur de hidden coupe simplement le contenu et en reste là.

overflow est en fait un raccourci pour définir à la fois overflow-x et overflow-y, respectivement pour le débordement horizontal et vertical. N'hésitez pas à utiliser ce qui vous convient le mieux.

Nous pouvons compléter overflow: hidden en ajoutant text-overflow: ellipsis. Le texte sera toujours coupé, mais nous aurons de jolis points de suspension à titre indicatif.

p {
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
}

voirtext-overflow: ellipsisde Will Boyd dansCodePen

Astuce bonus : saut de ligne en pseudo-élément

Vous pouvez forcer un saut de ligne avant et/ou après un élément ìnline, tout en le gardant comme élément inline`, avec une astuce de pseudo-élément.

Tout d'abord, définissez le content d'un pseudo-élément ::before ou ::after sur '\A', ce qui vous donnera le caractère de nouvelle ligne. Ensuite, définissez white-space: pre pour vous assurer que le caractère de nouvelle ligne est respecté.

<p>Things that go <span>bump</span> in the night.</p>

span {
  background-color: #000;
}
span::before, span::after {
  content: '\A';
  white-space: pre;
}

voirPseudo-Element Line Breaksde Will Boyd dansCodePen

Nous aurions pu simplement mettre display: block sur le <span> pour obtenir les mêmes retours à la ligne, mais il ne serait plus inline. Le background-color permet de voir facilement qu'avec cette méthode, nous avons toujours un élément inline.

Notes bonus

• Il existe une ancienne propriété CSS nommée word-wrap. Elle n'est pas standard et les navigateurs la traitent désormais comme un alias pour overflow-wrap.
• La propriété CSS white-space a d'autres valeurs que nous n'avons pas couvertes : pre-wrap, pre-line et break-spaces. Contrairement à celles que nous avons couvertes, celles-ci n'empêchent pas le retour à la ligne du texte.
• La spécification CSS Text Module Level 4 décrit une propriété CSS text-wrap qui semble intéressante, mais au moment de la rédaction, aucun navigateur ne l'implémente.

Il est temps de conclure

Il y a tellement de choses à dire à propos du texte fluide sur une page Web. La plupart du temps, vous n'avez pas vraiment besoin d'y penser, car les navigateurs le gèrent pour vous. Si vous avez besoin de plus de contrôle, il est bon de savoir que vous avez beaucoup d'options.

Écrire cet article a définitivement été un puits sans fond pour moi car je trouvais à chaque fois plus de choses à raconter. J'espère que je vous en ai montré assez pour que votre texte se coupe et s'écoule comme vous le souhaitez.

Merci d'avoir lu !

Le premier principe d'accessibilité du contenu dans les Web Content Accessible Guidelines est que le contenu doit être perceptible. Après tout, vous ne pourrez pas accéder à l'information ou à la fonctionnalité si vous ne savez pas qu'elle est là ! Et apparemment, le moyen le plus efficace de s'assurer que les utilisateurs ne pourront pas distinguer votre contenu est de le définir dans une couleur qui ne se démarque pas de son arrière-plan — en d'autres termes, d'avoir un faible contraste de couleur.

Nous pouvons tous rencontrer un problème lié à un contraste insuffisant, pour diverses raisons — par exemple à cause du reflet du soleil sur notre écran — mais le contraste insuffisant d'un texte a un impact démesuré sur les utilisateurs malvoyants tels que ceux qui ont des problèmes de vision ou qui sont daltoniens. Et pourtant, le texte à faible contraste est partout. Le rapport WebAIM Million pour 2022 a révélé que près de 84 % des 1 million de pages d'accueil les plus populaires avaient au moins une violation de contraste insuffisant, avec une moyenne de 31,6 instances distinctes de texte faiblement contrasté par page d'accueil. Un rapport de 2021 de Deque Systems (PDF) a révélé que le texte à faible contraste représentait 30 % des défauts d'accessibilité automatiquement détectables, ce qui en fait de loin le défaut d'accessibilité le plus courant.

Corriger l'insuffisance de contraste pourrait grandement contribuer à rendre le Web plus utilisable. Nous allons voir comment mesurer le contraste, corriger facilement un faible contraste et assurer un contraste suffisant dans nos sites à l'avenir.

Obtenez un ratio

Le plus simple pour commencer est d'utiliser un contrôleur de contraste de couleur. Des outils tels que WebAIM Contrast Checker prennent une paire de couleurs que vous leur donnez et vous retournent un rapport de contraste. En attendant, si vous avez déjà déployé votre site et vos couleurs en direct pour le monde, vous pouvez utiliser des outils d'analyse d'accessibilité pleine page tels que l'extension ax DevTools, et ils effectueront des opérations de contraste des couleurs pour chaque bit de texte et d'arrière-plan sur votre page et identifieront les éléments spécifiques de votre page dont le contraste est insuffisant. Dans tous les cas, vous obtiendrez un rapport de contraste des couleurs.

Ces ratios prennent le format <un certain nombre>:1, allant de 1:1 (pas de contraste — vous avez comparé une couleur à elle-même) à 21:1 (contraste maximum, uniquement obtenu en comparant le noir et blanc). Plus le premier chiffre est élevé, plus il y a de contraste entre les deux couleurs.

Ce rapport n'est pas vraiment un score de la différence entre les deux couleurs, mais plutôt un score de la façon dont une couleur serait perceptible par dessus l'autre. Par exemple, en tant que personne non daltonienne, les couleurs CSS tomato #ff6347 et cornflowerblue #6495ed me semblent très différentes :

En matière de font-size, on peut dire qu'on a fait du chemin. Je me rappelle une époque où il était encore courant d'utiliser une taille d'affichage de 10 pixels (ou moins), afin d'entasser autant de texte que possible dans un espace disponible de 640x480. De nos jours, les arguments en faveur d'une ligne de base de 16 pixels (1) sont assez largement acceptés. De nombreuses données confirment sa lisibilité, elle peut empêcher le zoom accidentel dans les navigateurs de portables, et c'est la valeur par défaut dans la plupart des navigateurs depuis maintenant plusieurs années.

Pourtant, de nombreux arguments militent en faveur de tailles de polices encore plus grandes :

• Des études ont montré que les polices plus grandes amélioraient la compréhension. Dans une étude de 2012, la taille idéale était estimée entre 18 et 22 pixels. (2)
• Des polices plus grandes sont plus accessibles. Le Ministère de la Santé américain recommande une taille de police d'au moins 19 pixels si votre lectorat comprend des personnes ayant des difficultés de lecture ou ayant un certain âge.
• La tendance actuelle va déjà dans ce sens : les sites offrant beaucoup de contenu, comme Medium, Vox et le Washington Post (pour n'en citer que quelques-uns) vont bien au-delà de 16 pixels pour le corps de texte, même sur les écrans réduits.
• Certaines polices semblent plus petites que d'autres à 16 pixels. Si votre police est fine, condensée ou si elle a une faible hauteur d'x, 16 pixels ne suffiront pas.
• Grâce à des fonctionnalités comme CSS clamp, nos tailles de polices peuvent être aussi fluides que nos mises en page, et s'agrandir depuis un minimum lisible jusqu'à un maximum que nous choisissons selon les paliers responsifs voulus.

Malgré ces arguments, j'ai constaté une certaine résistance à l'utilisation d'une taille de police supérieure. Ce n'est pas du tout surprenant, on voit de même certaines fonctionnalités de navigateurs ou de bonnes pratiques d'usabilité prendre du temps pour être adoptées, et tout ce qui n'est pas familier est difficile à vendre.

Sur quelques projets bien différents, avec des publics, des identités visuelles et des polices de caractères très divers, la réaction que j'entends le plus souvent concernant les polices plus grandes est qu'elles semblent assez enfantines, "on dirait un livre pour enfants".

Tirés de leur contexte, ces termes pourraient avoir l'air péjoratifs, mais je veux le dire clairement : nos clients sont polis, aimables, et nous leur demandons un retour franc et sans filtre. C'est pour moi un succès d'obtenir un avis honnête, qui est une marque de confiance, plutôt que des formulations indirectes. Et ça rend les patterns de feedbacks comme celui-ci bien plus faciles à repérer !

Alors, pourquoi "enfantin" ? Je pense que si cette réponse revient fréquemment c'est qu'elle renvoie à une expérience partagée. Nous avons tous été enfants, nous avons tous vu des livres pour enfants, et les astuces qui rendent la typographie accessible aux enfants sont les mêmes que celles qui aident les adultes ayant des niveaux variables d'alphabétisation, d'acuité visuelle et d'attention : des polices ayant une hauteur d'x généreuse, un espacement équilibré des mots et des lignes, des longueurs de ligne raisonnables, un alignement cohérent et un contraste adéquat. (3)

Mais si ces caractéristiques aident aussi bien les enfants que les adultes, pourquoi le texte de nos magazines imprimés, de nos romans, journaux et modes d'emploi est-il plus petit ?

En partie sans doute à cause du contenu : plus le lecteur est expérimenté, plus l'information peut être complexe. Les passages de texte plus longs bénéficient de sections et de titres, avec des tailles (plus grandes et plus petites) et des styles (graisse, casse, etc.) contrastés pour établir la hiérarchie. Des tableaux, des graphiques et des figures peuvent être utilisés pour faire comprendre des relations complexes, nécessitant une certaine densité d'informations pour être utiles. Ces considérations sont toujours pertinentes dans nos expériences numériques.

Mais je soupçonne malgré tout que la principale explication du rétrécissement typographique des longs formulaires se résume aux limites physiques de la page imprimée. Un texte plus gros signifie plus de pages, ce qui signifie plus de papier, d'encre et de matériaux de reliure… plus de travail et de carburant pour concevoir, imprimer, assembler et expédier… plus d'espace occupé sur nos étagères et dans nos bagages. Il n'est tout simplement pas pratique pour votre roman préféré d'augmenter considérablement sa taille de police sans augmenter son coût, ou devenir physiquement difficile à lire lorsqu'on est allongé sur le canapé.

Le design Web quant à lui a aussi ses limites, mais le nombre de pages n'en est pas une : nos navigateurs sont des fenêtres sur un canevas infini de contenu. Nous nous fichons bien que Wikipedia remplisse plus de 3 000 volumes imprimés, car il n'a jamais à le faire : nos appareils ne grossiront pas ou ne s'alourdiront pas en le lisant sur notre navigateur, quelle que soit la taille de la police.

Donc, à moins d'entendre un argument plus convaincant, je vais continuer à préconiser des tailles de police plus grandes pour des passages de contenu plus longs, en prenant soin de préserver la hiérarchie et la densité de l'information, le cas échéant. 18 ou 20 pixels peuvent sembler assez grands à première vue pour nous qui sommes tellement habitués à plisser les yeux à 16 ou moins, mais les données sont claires et les avantages de lisibilité sont immédiats. (4)

    1 - J'utilise les pixels tout au long de cet article pour la clarté, mais vous devriez probablement utiliser les unités proportionnelles (em, rem, etc.) quand c'est possible. ↩

    2 - L'étude utilise des points, mais ce sont des points CSS, ils correspondent donc à des pixels. Les points sont d'une taille différente à l'impression (environ un tiers plus grand ?), j'ai donc utilisé le terme "pixels" ici pour plus de cohérence dans l'article ↩

    3 - Une de mes premières hypothèses était que les polices plus grandes exposaient plus de similitudes entre les polices de caractères d'entreprise et celles des livres ou des produits pour enfants, mais cette idée s'est effondrée lorsque je me suis familiarisé à nouveau avec la variété stupéfiante des traitements typographiques dans les œuvres pour enfants. ↩

    4 - Certains pourraient dire que c'est un point discutable… nos utilisateurs les plus avertis peuvent redimensionner le texte comme ils le souhaitent. Pour moi, c'est comme demander à nos utilisateurs de tenir l'écran plus près de leur visage : c'est toujours une option, mais une défense fragile pour une décision de design. ↩

Avec Grid, on peut toujours placer les items entre une ligne de grille et une autre. Mais il existe une autre façon de décrire notre mise en page, une façon plus visuelle. Dans ce troisième volet de notre série nous allons voir comment utiliser la propriété grid-template-areas pour définir un placement sur la grille et nous découvrirons comme elle fonctionne réellement.

Décrire une mise en page avec grid-template-areas

La propriété grid-template-areas accepte pour valeur une ou plusieurs chaînes de caractères. Chacune, entourée de guillemets, représente une rangée de notre grille. Nous pouvons utiliser la propriété sur une grille définie avec grid-template-rows et grid-template-columns, ou nous pouvons créer notre mise en page, auquel cas toutes les rangées seront automatiquement dimensionnées.

La propriété et les valeurs qui suivent décrivent une grille comportant quatre zones — chacune s'étend sur deux pistes de colonnes et deux pistes de rangées. Une zone (area) peut s'étendre sur plusieurs pistes lorsqu'on en répète le nom dans toutes les cellules qu'on veut couvrir :

grid-template-areas: "one one two two"
                     "one one two two"
                     "three three four four"
                     "three three four four";

Les items sont placés dans la mise en page en étant nommés dans la propriété grid-area. Si nous voulons placer un élément ayant une classe test dans la zone de la grille qui s'appelle one, il suffit d'écrire :

.test {
  grid-area: one;
}

Regardons cela en action dans le codepen qui suit. J'ai quatre items, avec des classes nommées un à quatre (one to four), qui sont assignées aux zones de grille correspondantes via la propriété grid-area et qui s'affichent donc dans les boîtes correctes de la grille.

voirGrid template areas : exemple simplede rachelandrew dansCodePen

Si vous utilisez l'inspecteur Grid de Firefox, vous pouvez voir les noms des zones et les lignes de grille, montrant que chaque item s'étend en effet sur deux rangées et deux colonnes — le tout sans faire aucun positionnement basé sur les lignes pour l'item lui-même.

Règles d'utilisation de grid-template-areas

Il ya des règles à suivre lorsqu'on crée une mise en page de cette façon. Ne pas les respecter rendra les valeurs invalides et notre mise en page ne fonctionnera pas. La première règle est que nous devons décrire une grille complète, chaque cellule de la grille doit être remplie.

Si l'on veut laisser une ou plusieurs cellules vides, on exprime ce choix en insérant un point . ou une série de points ... sans espace entre eux.

Si je change les valeurs de notre grille ainsi :

grid-template-areas: "one one two two"
                     "one one two two"
                     ". . four four"
                     "three three four four";

j'ai maintenant deux cellules sans contenu à l'intérieur. L'item three n'est affiché que dans la dernière rangée de la grille.

Nous ne pouvons définir chaque zone qu'une seule fois, c'est à dire que nous ne pouvons utiliser cette propriété pour copier du contenu à deux endroits sur la grille ! Les valeurs qui suivent seraient invalides et la propriété dans son ensemble serait ignorée, car nous avons dupliqué la zone three :

grid-template-areas: "one one three three"
                     "one one two two"
                     "three three four four"
                     "three three four four";

On ne peut pas non plus créer une zone non-rectangulaire, la propriété ne peut pas être utilisée pour créer une zone en forme de T ou de L, et les valeurs ci-dessous sont également invalides :

grid-template-areas: "one one two two"
                     "one one one one"
                     "three three four four"
                     "three three four four";

Formater les chaînes de caractères

Dans mon CSS, j'aime bien afficher les valeurs de grid-template-area comme je le fais ci-dessus, avec chaque chaîne de caractères qui représente une rangée et chacune disposée en-dessous de la rangée précédente, car cela me donne une représentation visuelle de ma mise en page.

Pour améliorer encore la visualisation, on peut ajouter des espaces entre chaque cellule, mais aussi des points multiples pour les cellules vides, ainsi tout est bien aligné :

grid-template-areas: "one   one   two  two"
                     "one   one   two  two"
                     "..... ..... four four"
                     "three three four four";

Ceci étant, on peut, de manière tout à fait valide, aligner toutes les chaînes de caractères sur une seule ligne, on pourrait donc écrire :

grid-template-areas: "one one two two" "one one two two" "three three four four" "three three four four";

Expliquer grid-template-areas et grid-area

La raison pour laquelle chaque zone doit être un rectangle complet est qu'elle doit avoir la même forme que si elle avait été créée par un placement basé sur les lignes. Si nous poursuivons avec notre exemple précédent, nous pourrions réaliser cette mise en page avec des lignes de grille comme dans le codepen ci-dessous. Ici, j'ai créé ma grille comme avant. Cette fois par contre, j'ai utilisé les lignes de grille pour positionner via les propriétés (raccourcies) grid-column-start, grid-column-end, grid-row-start et grid-row-end.

voirGrid template areas : placement basé sur les lignesde rachelandrew dansCodePen

Note : si vous avez lu mon précédent article Comprendre CSS Grid : les lignes Grid vous savez déjà qu'il est possible d'utiliser grid-area comme un raccourci pour déclarer les quatre lignes en une fois.

Cela signifie que nous pourrions aussi créer notre mise en page avec l'ordre de lignes suivant :

• grid-row-start
• grid-column-start
• grid-row-end
• grid-column-end

.one {
  grid-area: 1 / 1 / 3 / 3;
}
.two {
  grid-area: 1 / 3 / 3 / 5;
}
.three {
  grid-area: 3 / 1 / 5 / 3;
}
.four {
  grid-area: 3 / 3 / 5 / 5;
}

la propriété grid-area est intéressante en ce qu'elle peut prendre des numéros de ligne ou des noms de ligne. Mais il est important de comprendre comment elle fonctionne dans chaque mode.

Utiliser grid-area avec des numéros de ligne

Si vous utilisez la propriété grid-area avec des numéros de ligne, alors les lignes seront assignées dans l'ordre décrit ci-dessus.

Si vous omettez des valeurs — en ne fournissant qu'un, deux, ou trois numéros de ligne — les valeurs manquantes sont réglées sur auto ce qui signifie que la zone s'étendra sur une piste (ce qui est la valeur par défaut). Donc le CSS suivant placerait un item grid-row-start: 3 avec toutes les autres valeurs réglées sur auto, et donc, l'item serait auto-placé dans la première piste de colonne disponible, et s'étendrait sur une piste de rangée et une piste de colonne.

grid-area: 3;

Utiliser grid-area avec des idents

Si nous utilisons ident (qui est la façon pour Grid Layout d'appeller une zone nommée), alors la propriété grid-area prend aussi quatre lignes. Si vous avez des lignes nommées dans votre grille, comme décrit dans Comprendre CSS Grid : créer un container Grid, alors vous pouvez utiliser ces lignes nommées tout comme les lignes numérotées.

Attention cependant car, selon que vous utilisez ident avec des lignes nommées ou numérotées, le comportement sera différent dans le cas où vous omettez quelques lignes.

Ci-dessous, j'ai créé une grille avec des lignes nommées et utilisé grid-area pour placer un item (en omettant la valeur finale) :

.grid {
  display: grid;
  grid-template-columns:
      [one-start three-start] 1fr 1fr
      [one-end three-end two-start four-start] 1fr 1fr [two-end four-end];
  grid-template-rows:
    [one-start two-start] 100px 100px
    [one-end two-end three-start four-start] 100px 100px [three-end four-end];;
}
.two {
  grid-area: two-start / two-start / two-end;
}

Il nous manque donc le nom de ligne pour grid-column-end. La spécification dit que dans cette situation, grid-column-end doit utiliser une copie de grid-column-start. Si grid-column-end et grid-column-start sont identiques, alors la ligne finale est oubliée, et la valeur est réglée sur auto, donc l'item s'étend sur une piste, comme dans la version numérotée.

La même chose se produit si nous omettons la troisième valeur grid-row-end ; elle devient la même que grid-row-start et donc devient auto.

Jetez un œil à cet exemple codepen de la façon dont grid-area est utilisé et comment il change ensuite la mise en page de l'item :

voirGrid template areas : idents manquants dans grid-areade rachelandrew dansCodePen

Ceci explique pourquoi grid-area fonctionne avec une seule valeur ident représentant une zone nommée.

Quand nous créons une zone nommée avec la propriété grid-template-areas, le bord de chaque zone peut être référencé par un nom de ligne qui est le même que le nom de la zone utilisée. Dans notre cas, nous avons pu prendre notre zone nommée one et placer notre item en utilisant des lignes nommées comme suit :

.one {
  grid-row-start: one;
  grid-row-end: one;
  grid-column-start: one;
  grid-row-end: one;
}

Quand nous disons grid-area: one, nous omettons les trois dernières valeurs du raccourci grid-area ; elles finissent comme des copies de notre première valeur — toutes, dans notre cas deviennent one et l'item est placé exactement comme dans la version longue de notre css.

Le fonctionnement du nommage dans Grid layout est très intelligent et permet des choses bien intéressantes que j'ai décrites dans mes articles précédents Naming Things In CSS Grid Layout et Editorial Design Patterns With CSS Grid And Named Columns (en anglais).

Mettre en page des items avec grid-template-areas

Avec grid-template-areas, une cellule ne peut être occupée que par un seul nom, cependant nous pouvons toujours ajouter des items à la grille après avoir réalisé notre mise en page principale de cette manière. Pour cela, nous avons les lignes numérotées, comme d'habitude.

Dans l'exemple codepen suivant, j'ai ajouté un item supplémentaire et je l'ai placé par-dessus les items déjà présents en utilisant le positionnement basé sur les numéros de lignes.

voirGrid template areas : placer un item avec des numéros de lignesde rachelandrew dansCodePen

Nous pouvons également utiliser les noms de lignes définis lorsque nous avons créé nos colonnes ou rangées. Mieux encore, nous aurons des noms de lignes créés par la formation des zones. Nous avons déjà vu comment nous pouvons obtenir quatre noms de lignes à partir du nom de la zone. Nous obtenons aussi une ligne de début au bord de chaque zone avec un -start ajouté au nom de la zone, et une ligne pour l'autre bord avec un -end ajouté.

Par conséquent, la zone nommée one a des lignes de début appelées one-start et de fin appelées one-end.

Nous pouvons ensuite utiliser ces noms implicites de lignes pour placer une item sur la grille. Cela peut être utile si on redéfinit la grille à plusieurs points de rupture (breakpoints), si nous voulons toujours que l'tem placé se trouve après un certain nom de ligne.

voirGrid template areas : placer un item avec des noms implicites de lignesde rachelandrew dansCodePen

Utiliser grid template areas dans un design responsif

Je construis souvent des composants et je me rends compte que grid-template-areas peut être bien utile pour voir exactement, déjà dans le CSS, à quoi mon composant va ressembler. De plus, la redéfinition du composant pour plusieurs points de rupture est très simple, il suffit de redéfinir les valeurs de grid-template-areas, avec parfois en plus un changement du nombre de pistes de colonnes.

Dans le CSS qui suit, j'ai défini une mise en page à une seule colonne pour mon composant. Ensuite, à une largeur minimum de 600px, je redéfinis le nombre de colonnes ainsi que la valeur de grid-template-areas afin de créer une mise en page sur deux colonnes. Ce qui est bien avec cette approche, c'est qu'il suffit de regarder le CSS pour voir à quoi ressemble ma mise en page !

.wrapper {
  background-color: #fff;
  padding: 1em;
  display: grid;
  gap: 20px;
  grid-template-areas:
    "hd"
    "bd"
    "sd"
    "ft";
}
@media (min-width: 600px) {
  .wrapper {
    grid-template-columns: 3fr 1fr;
    grid-template-areas:
      "hd hd"
      "bd sd"
      "ft ft";
  }
}
header { grid-area: hd; }
article {grid-area: bd; }
aside { grid-area: sd; }
footer { grid-area: ft; }

Accessibilité

Il faut être prudent lorsqu'on utilise cette méthode et se rappeler qu'elle peut amener à une réorganisation du contenu qui peut se trouver déconnecté de l'ordre de la source. Un utilisateur naviguant avec la tabulation regarde l'écran tout en écoutant un texte dit par l'ordinateur, et ce dernier lit le contenu dans l'ordre où il figure dans la source HTML. Cela peut entraîner beaucoup de confusion pour l'utilisateur.

Résumé

Voilà tous les tuyaux à connaître sur les propriétés grid-template-area et grid-area pour créer des mises en page. Si vous ne l'avez pas déjà utilisée, essayez là. Je la trouve très utile notamment pour expérimenter et je m'en sers beaucoup pour mes prototypes — même si, pour une raison ou une autre, je suis amenée plus tard à utiliser une autre méthode pour la production.

Dans le premier article de cette série, nous avons vu comment créer un container grid, et les diverses propriétés utilisables sur l'élément parent qui constitue notre grille. Une fois que nous avons une grille, nous avons un ensemble de lignes. Dans cet article, nous allons voir comment placer des items par rapport à ces lignes, en ajoutant des propriétés aux enfants directs de notre conteneur.

Ce que nous allons voir :

• Les propriétés de placement grid-column-start, grid-column-end, grid-row-start, grid-row-end et leur raccourci grid-column and grid-row.
• Comment utiliser grid-area pour un placement par numéro de ligne
• Comment placer des items avec un nom de ligne
• La différence entre les grilles implicite et explicite quand on place les items
• L'utilisation du mot-clé span (et une sous-grille en bonus)
• La vigilance nécessaire lorsqu'on mélange des items placés et auto-placés

Concepts de base du positionnement par ligne

Pour placer un item sur la grille, nous définissons la ligne depuis laquelle il part et celle où il s'arrête. Du coup, pour une grille de cinq colonnes et de cinq rangées, si je veux que mon item s'étende de la deuxième à à troisième piste de colonne, et couvre les première, deuxième et troisième rangées, j'utiliserai le CSS ci-dessous. Gardez à l'esprit que nous visons la ligne, non la piste elle-même.

.item {
  grid-column-start: 2;
  grid-column-end: 4;
  grid-row-start: 1;
  grid-row-end: 4;
}

On peut utiliser les raccourcis :

.item {
  grid-column: 2 / 4;
  grid-row: 1 / 4;
}

Dans Codepen, nous pouvons voir l'exemple et modifier les lignes :

voirGrid lines : raccourcis de placementde rachelandrew dansCodePen

Notez que la raison pour laquelle notre arrière-plan de boîte s'étend sur toute la surface est que les valeurs initiales des propriétés d'alignement align-self et justify-self sont stretch.

Si nous avons seulement besoin de couvrir une piste, nous pouvons omettre la ligne de fin, car le comportement par défaut est que les items s'étendent sur une piste. C'est ce que nous constatons lorsque nous plaçons automatiquement les items comme dans l'article précédent, chaque item va dans une cellule, à la croisée d'une colonne et d'une rangée. Pour indiquer que notre item doit s'étendre de la ligne 2 à la ligne 3, on pourrait écrire :

.item {
  grid-column: 2 / 3;
}

Il serait tout à fait correct d'omettre la ligne de fin :

.item {
  grid-column: 2;
}

Le raccourci grid-area

Nous pouvons aussi placer un item avec grid-area (zone de grille). Nous retrouverons cette propriété dans un prochain article, mais disons dès maintenant que lorsqu'on l'utilise avec les numéros de ligne il permet de régler les quatre lignes.

.item {
  grid-area: 1 / 2 / 4 / 4;
}

L'ordre de ces quatre lignes est grid-row-start, grid-column-start, grid-row-end, grid-column-end. Quand on travaille avec un langage écrit horizontalement, de gauche à droite (comme le français), c'est haut, gauche, bas, droite. Vous avez sans doute remarqué que c'est l'inverse de la façon dont on spécifie les raccourcis (pour les marges par exemple) en CSS, qui est haut, droite, bas, gauche.

La raison en est que Grid fonctionne de la même manière, quel que soit le mode ou la direction d'écriture — nous verrons cela tout à l'heure. Il est donc plus logique de définir d'abord les deux départs, puis les deux fins, plutôt que de se référer aux dimensions physiques de l'écran. Personnellement j'utilise peu ces propriétés pour le placement basé sur les lignes, car je trouve que les deux raccourcis grid-column et grid-row sont plus lisibles quand on lit rapidement une feuille de styles.

Les lignes sur la grille explicite

J'ai parlé des grilles explicites et implicites dans mon article précédent. Quand on crée une grille avec les propriétés grid-template-columns et grid-template-rows, on crée une grille explicite. En définissant les pistes de colonne et de rangée, on définit aussi les lignes entre ces pistes et les lignes au début et la fin de la grille.

Ces lignes sont numérotées. La numérotation commence à 1, au bord de la grille, dans la direction block comme inline. Si l'on est dans un mode d'écriture horizontal de gauche à droite, cela signifie que la ligne 1 dans la direction block est au sommet de la grille et la ligne 1 dans la direction inline est à gauche.

Si vous travaillez dans un langage horizontal de droite à gauche — par exemple dans une langue arabe — alors la ligne 1 dans la direction block est toujours au sommet, mais la ligne 1 dans la direction inline est à droite.

Si vous travaillez en mode d'écriture vertical (et dans l'exemple ci-dessous j'ai réglé sur writing-mode: vertical-rl), alors la ligne 1 sera au sommet dans la direction block de ce mode d'écriture, et donc dans ce cas à droite. La ligne 1 dans la direction inline est au sommet.

Les ligne de grille sont donc liées au mode et au sens d'écriture.

La ligne finale notre grille explicite a poour numéro -1 et les lignes sont numérotées à l'envers à partir de là, la deuxième ligne a donc pour numéro -2. Par conséquent, si vous voulez que votre item s'étende sur toutes les pistes de la grille explicite, vous pouvez écrire :

.item {
  grid-column: 1 / -1;
}

Les lignes sur la grille implicite

Si nous créons une grille implicite, les pistes sont aussi comptées à partir de 1. Dans l'exemple ci-dessous, j'ai créé une grille explicite pour les colonnes, mais les pistes de rangées ont été créées dans la grille implicite, où j'utilise grid-auto-rows pour les dimensionner à 5em.

L'item ayant une classe de placed a été placé pour s'étendre de la ligne de rangée 1 à la ligne de ragée -1. Si nous travaillions avec une grille explicite pour nos deux rangées, l'item s'étendrait sur deux rangées. Mais du fait que les pistes de rangées ont été créées dans la grille implicite, la ligne -1 est devenue la ligne 2 et non la ligne 3.

voirGrid lines : grille explicite vs implicitede rachelandrew dansCodePen

Actuellement il n'est pas possible de cibler la dernière ligne de la grille implicite si l'on ne sait pas combien de lignes on a.

Placer les items sur des lignes nommées

Dans le dernier article j'ai expliqué qu'en plus des lignes numérotées on a l'option de nommer les lignes sur la grille. On nomme les lignes en ajoutant un ou plusieurs noms entre crochets avant la taille de la piste.

.grid {
  display: grid;
  grid-template-columns: [full-start] 1fr [main-start] 2fr 2fr [main-end full-end];
}

Une fois qu'on a nommé les lignes, on peut remplacer le numéro de ligne par un nom quand on place les items :

.item {
  grid-column: main-start / main-end;
}

voirGrid lines : nommer les lignesde rachelandrew dansCodePen

Si votre ligne a plusieurs noms, vous pouvez prendre celui que vous voulez pour placer votte item, tous les noms se rapporteront à la même ligne.

Note: il se passe des choses intéressantes quand on nomme les choses, voyez mon article Naming Things in CSS Grid Layout (en anglais).

Que se passe-t-il si nous avons plusieurs lignes avec le même nom ?

On observe un comportement intéressant quand on a plusieurs lignes qui ont le même nom. Cette situation pourrait se produire si nous nommons nos lignes dans une notation repeat(). Dans l'exemple qui suit, j'ai défini une grille de 8 colonnes, créée en répétant quatre fois un pattern de 1fr 2fr. J'ai nommé sm la ligne avant la petite piste et lg la piste après. J'ai donc quatre lignes avec le même nom.

Dans cette situation, nous pouvons utiliser le nom comme un index. Donc pour placer un item qui commence à la deuxième ligne (appelée sm) et s'étend jusqu'à la troisième ligne (appelée lg), j'utilise grid-colum: sm 2 / lg 3. Si on utilise le nom sans un numéro, on ciblera toujours la première occurrence de cette ligne avec ce nom.

voirGrid lines : nommer les lignesde rachelandrew dansCodePen

Utiliser le mot-clé span

Dans certains cas, vous savez que vous voulez avoir un item qui s'étend sur un certain nombre de pistes, mais vous ne savez pas exactement où dans la grille. Un exemple d'une telle situation serait un cas où vous placez des items avec auto-placement, mais vous voulez qu'ils s'étendent sur plusieurs pistes, plutôt que sur 1fr (qui est le défaut). Dans ce cas, vous pouvez utiliser le mot-clé span. L'exemple ci-dessous montre un item qui commence à la ligne auto, c'est la ligne où l'auto-placement le mettrait, et il couvre ensuite trois pistes.

.item {
  grid-column: auto / span 3;
}

voirGrid lines : le mot-clé spande rachelandrew dansCodePen

Cette technique deviendra très utile quand la valeur subgrid sera largement supportée pour grid-template-columns et grid-template-rows. par exemple, dans une mise en page d'encarts, où chaque encart comporte un header et un contenu principal, que vous voulez alignés, vous pouvez avoir chaque encart qui s'étend sur 2 rangées, tout en permettant le comportement habituel d'auto-placement. Les encarts individuels utiliseront subgrid pour leurs rangées (deux rangées pour chacun). On peut le voir dans l'exemple suivant :

voirGrid lines : le mot-clé span et les subgridsde rachelandrew dansCodePen

Le même exemple vu avec Firefox Grid Inspector :

Placement d'items basé sur les lignes

Grid place automatiquement les items dans des cellules vides de la grille, il ne va pas les empiler dans la même cellule. Cependant, en utilisant le placement basé sur les lignes, nous pouvons mettre les items dans la même cellule. Dans l'exemple ci-dessous, j'ai une image qui s'étend sur deux pistes et une légende placée après la deuxième piste et à laquelle j'ai donné un fond semi-transparent.

voirGrid lines : encarts et éléments empilésde rachelandrew dansCodePen

Les items s'empilent dans l'ordre dans lequel ils apparaissent dans la source. par conséquent, la légende vient après l'image et s'affiche par-dessus. Si la légende venait en premier, elle serait cachée par l'image. nous pouvons contrôler cet empilement avec la propriété z-index. S'il était important d'avoir la légende avant l'image dans la source, on utiliserait z-index avec une valeur supérieure à celle de l'image, ce qui forcerait la légende à s'afficher par-dessus l'image.

Mélanger placement automatique et basé sur les lignes

Si l'on souhaite mélanger le placement d'items basé sur les lignes et le placement automatique, il nous faut être bien attentif. Quand les items sont tous auto-placés dans une grille, ils se placeront de manière séquentielle, chacun trouvant l'espace disponible suivant pour se positionner.

voirGrid lines : auto-placementde rachelandrew dansCodePen

Le comportement par défaut est toujours d'avancer, et de laisser un gap si un item ne rentre pas dans la grille. Nous pouvons contrôler ce comportement avec la propriété grid auto flow et une valeur de dense. Dans ce cas, si un item entre dans un espace déjà laissé vide dans la grille, il sera placé en dehors de l'ordre de la source afin de remplir cet espace. Dans l'exemple suivant, qui utilise dense, l'item 3 est maintenant placé avant l'item 2.

voirGrid lines : auto-placement et densede rachelandrew dansCodePen

Notez que ce comportement peut poser des problèmes aux lecteurs qui utilisent la touche tabulation car le contenu visuel sera décalé par rapport à la source.

Auto-placement fonctionne un peu différemment si vous avez déjà placé quelques items. Les items placés seront positionnés en premier, puis auto-placement cherchera les espaces disponibles pour placer les items. Si vous avez laissé de l'espace blanc en haut de votre mise en page avec une rangée vide, introduisez quelques items qui seront auto-placés, ils se retrouveront dans cette piste.

Pour le montrer, dans cet exemple final j'ai placé les items 1 et 2, avec la propriété basée sur les lignes, en laissant la première rangée vide. Les derniers items sont maintenant les premiers.

voirGrid lines : auto-placement et items placésde rachelandrew dansCodePen

Il est important de comprendre ce comportement, car on peut se retrouver avec des items placés de manière étrange si on introduit dans la mise en page de nouveaux éléments auxquels on n'aurait pas donné un placement dans la grille.

Conclusion

C'est à peu près tout ce que vous devez savoir sur les lignes de grille. Rappelez-vous que vous avez toujours les lignes numérotées, et vous pouvez toujours placer un item d'un numéro de ligne à un autre. Les autres méthodes que nous verrons bientôt sont des méthodes alternatives, mais sont basées sur les lignes numérotées.

Nous commençons ici une nouvelle série d'articles consacrés à CSS Grid Layout, publiés dans Smashing Magazine. Grid est disponible depuis 2017, mais de nombreux développeurs n'ont pas encore eu l'occasion de l'utiliser dans le cadre d'un projet. A première vue, Grid vient avec toute une foule de propriétés et de valeurs, ce qui peut sembler rebutant. Mais en réalité, de nombreux détails de la spécification sont des variantes, ce qui signifie que vous n'avez pas besoin d'apprendre la spécification entière pour commencer. Cette série vise à vous faire passer de débutant à expert de Grid — et vous donnera de nombreux conseils pratiques en cours de route.

Dans ce premier article nous allons voir ce qui se passe lorsqu'on crée un grid container (conteneur de grille) et les diverses propriétés que vous pourrez utiliser sur l'élément parent pour contrôler cette grille. Vous découvrirez qu'il existe plusieurs cas d'utilisation qui ne sont réalisables qu'avec les propriétés de grid container. Dans cet article, nous couvrirons:

• Création d'un grid container avec display: grid ou display: inline-grid,
• Configuration des colonnes et des lignes avec grid-template-columns et grid-template-rows,
• Contrôle de la taille des pistes (tracks) implicites avec grid-auto-columns et grid-auto-rows.

NdT : les termes utilisés ici (pistes,...) sont des termes techniques qu'il faut connaître, nous renverrons à chaque fois que nécessaire vers le Guide Complet de CSS Grid Layout traduit ici.

Créer un container grid

Grid, comme Flexbox, est une valeur de la propriété display. Par conséquent, pour indiquer au navigateur qu'on utilise la mise en page grid, on écrit display:grid dans le css de l'élément. Le navigateur nous donne une boîte de niveau block sur l'élément en question et tout enfant direct sera inclus dans le contexte de formatage grid. Ils se comporteront comme des items grid et non comme des éléments block ou inline normaux.

Vous ne verrez sans doute aucune différence immédiate dans votre page à ce stade. Comme vous n'avez encore créé ni ligne ni colonne, vous avez une grille à une colonne. Suffisamment de rangées sont générées pour contenir tous les enfants directs et ils s'affichent l'un après l'autre dans cette colonne unique. Visuellement, ils ont l'air d'éléments block.

On verrait une différence si l'on avait à la fois une chaîne de caractères, non enveloppée dans un élément, et un enfant direct du container grid, du fait que cette chaîne de caractères serait enveloppée dans un élément anonyme et deviendrait un item grid. Tout élément normalement inline, comme un span par exemple, devient un item grid dès lors que son parent est un container grid.

L'exemple qui suit montre deux éléments de niveau block et un texte contenant une span au milieu de la chaîne de caractères. On se retrouve avec cinq items grid :

• les deux éléments div
• la chaîne de caractères qui précède le span
• le span lui-même
• la chaîne de caractères qui suit le span

voirGrid container : enfants directs et chaîne deviennent des items gridde rachelandrew dansCodePen

Si l'on inspecte la grille avec Firefox Grid Inspector, on voit les cinq rangées qui ont été crées pour nos items.

Il est possible de créer une grille inline avec display: inline-grid ; dans ce cas, notre container devient une boîte de niveau inline. Les enfants directs sont toujours des items grid et se comportent comme les items grid à l'intérieur d'une boîte de niveau block (c'est seulement le type d'affichage extérieur). C'est pourquoi le container grid se comporte de la même façon que précédemment quand il est avec avec d'autres boîtes dans une page.

L'exemple suivant montre une grille suivie d'une chaîne de caractères. Comme c'est une grille de niveau inline, le texte peut s'afficher à côté (les éléments de niveau inline ne s'étirent pas pour prendre toute la place dans la dimension inline, contrairement aux éléments de niveau block).

voirGrid container : inline-gridde rachelandrew dansCodePen

Note : à l'avenir, on pourra mieux décrire notre layout en utilisant display: block grid pour créer un container de niveau block et display inline grid pour créer un container de niveau inline.

Colonnes et rangées

Pour obtenir quelque chose qui ressemble à une grille, nous aurons besoin d'ajouter des colonnes et des rangées. Pour cela on utilise les propriétés grid-template-columns et grid-template-rows. Dans la spécification il est dit que ces propriétés acceptent une valeur appelée track-list (une liste de pistes).

Ces propriétés spécifient, sous forme d'une liste de pistes séparées par un espace, les noms des lignes et les fonctions de dimensionnement des pistes de la grille. La propriété grid-template-columns spécifie la liste de pistes pour les colonnes de la grille, tandis que grid-template-rows le fait pour les rangées.

A titre d'illustration, voici quelques valeurs de listes de pistes possibles :

• grid-template-columns: 100px 100px 200px; crée une grille à trois colonnes: la première fait 100px de large, la deuxième aussi, la troisième fait 200px.

• grid-template-columns: min-content max-content fit-content(10em); crée une grille à trois colonnes, la première à la taille min-content, la deuxième à la taille max-content. La troisième est à la taille max-content sauf si le contenu est plus grand que 10em, auquel cas il est limité à 10em.

• grid-template-columns: 1fr 1fr 1fr; crée une grille à trois colonnes à l'aide de l'unité fr. L'espace disponible dans le container grid est divisé en trois et partagé entre les trois colonnes.

• grid-template-columns: repeat(2, 10em 1fr); crée une grille de quatre colonnes selon un motif répété 10em 1 fr 10em 1fr, la liste de pistes étant répétée deux fois.

• grid-template-columns: repeat(autofill 200px); remplit le container d'autant de colonnes de 200px que possible, et laisse un espace à la fin s'il reste de la place.

• grid-template-columns: repeat(autofill minmax(200px, 1fr)); remplit le container d'autant de colonnes de 200px que possible, puis distribue l'espace restant de manière égale entre les colonnes.

• grid-template-columns: [full-start] 1fr [content-start] 3fr [content-end] 1fr [full-end]; crée une grille de trois colonnes, la première et la troisième occupant une fraction de l'espace disponible et la troisième occupant trois fractions de l'espace disponible. Les lignes sont nommées en mettant leur nom entre crochets.