
Le web est plus fort lorsqu’il est divers&nbsp;: plus il est accessible, meilleur est ce qu’il nous offre. L’attribut `alt` est un exemple déjà ancien de ce que nous pouvons faire pour améliorer l’accessibilité, mais pour bien écrire un texte alternatif pour vos images il est utile de connaître quelques règles.

## L'attribut alt

Qu'est-ce que l'attribut `alt` ? c'est la **représentation alternative d’une image sous forme de texte**. Si une image ne se charge pas ou si elle est bloquée, la valeur de l’attribut `alt` s’affichera à la place. Les utilisateurs d’outils pour l'accessibilité pourront entendre le texte lu à haute voix ou lire sa transcription en braille. Optimiser `alt` est également utile pour le SEO, car il fait partie des informations permettant aux moteurs de recherche de déterminer le contenu d’une image et d’associer votre site aux termes de recherche.

L’attribut `alt` (souvent appelé par erreur la “balise alt”) est obligatoire pour tous les éléments `<img>` de votre site. La plupart du temps, la façon la plus simple de rédiger un texte alternatif est **d’écrire ce que vous diriez si vous faisiez le description de l’image à quelqu’un**. Par exemple une photographie de canal à Amsterdam pourrait être décrite ainsi&nbsp;:

```
<img src="singel.jpg" alt="Crépuscule à Jordaan, Amsterdam, Hollande">
```

Ou encore (et mieux) :

```
<img src="singel.jpg" alt="Une rangée de maisons aux fenêtres illuminées le long d’un canal à Amsterdam">
```

D’une manière générale, plus le texte est descriptif, meilleur il est.

### Exceptions à alt : les logos

**Si le contenu principal d’une image est un texte, les règles changent**. Les images bitmap présentant un texte intégré, comme celle-ci&nbsp;:

<figure role="group"><img src="/images/festa-del-rederentore.png" alt="Festa Del Rederentore, Venezia ~ Dal 1577"/></figure>

…devrait avoir **une valeur d’attribut `alt` reflétant directement le texte de l’image**.

```
<img src="festa-del-rederentore.png" alt="Festa Del Rederentore, Venezia ~ Dal 1577">
```

La raison en est simple : la plupart des lecteurs d’écran ne savent pas bien reconnaître et traduire le texte d’une image, celui-ci est donc impénétrable à la fois pour les moteurs de recherche et pour les personnes malvoyantes. En plaçant le texte dans `alt`, vous faites la traduction pour eux.

_NB&nbsp;: vous verrez souvent ce genre de balisage pauvre, Ne faites pas cela&nbsp;_:

```
<img src="logo.gif" alt="Logo">
```

C’est aussi une excellente raison d’utiliser le [SVG](/tags/svg/) en ligne pour les logos. Correctement construit, un logo SVG sera un vrai texte, lisible par tous. Il est important de noter que si le texte est dispersé en plusieurs chemins SVG, sa valeur sémantique est perdue. Une solution alternative (et peut-être meilleure) est de conserver la partie graphique du logo en SVG et d’écrire le reste dans le balisage auquel on appliquera un style. Bien sûr les deux options doivent être examinées en tenant compte du temps que prendra le chargement d’une police de caractères embarquée.

### alt vide

Il y a deux cas dans lesquels on peut laisser vide l’attribut `alt`&nbsp;:

- l’image est purement décorative, c’est à dire qu’elle n’a pas de valeur informative;
- l’image est décrite de manière appropriée par un élément sémantique qui la suit immédiatement, généralement une légende `<figcaption>`.

Si vous voulez que votre page reste valide, `alt` doit malgré tout être présent dans `<img>`, et pour indiquer qu’il est vide on lui donne la valeur `""` (guillemets ouvrant et fermant sans espace entre les deux).

```
<img src="flourish.png" alt="">
```

Une autre solution en HTML5 est de laisser l’attribut `alt` sans valeur&nbsp;:

```
<img src="flourish.png" alt>
```

Dans certaines occasions rares, la valeur de `alt` peut être très proche du [texte en légende (`<figcaption>`)](http://thenewcode.com/413/Captioning-images-in-HTML5), dans ce cas le texte alternatif est redondant et peut être laissé vide.

```
<figure>
	<img src="rio-di-san-barnaba.jpg" alt>
	<figcaption>Photograph down the canal of the Rio di San Barnaba, Venice</figcaption>
</figure>
```

Les différences peuvent être subtiles : `alt` **décrit** une image, alors que `<figcaption>` **intitule** le contenu de l’élément `<figure>`. Dans la plupart des cas, les deux seront différents et devraient donc être conservés&nbsp;:

```
<figure>
	<img src="doge-portrait.jpg" alt="Peinture à l'huile représentant un homme âgé portant un couvre-chef et un manteau brodé">
	<figcaption>Portrait du Doge Leonardo Loredan par Giovanni Bellini</figcaption>
</figure>
```

<figure role="group"><img src="/images/Giovanni_Bellini-_portrait_of_Doge_Leonardo_Loredan.jpeg" alt="Peinture à l'huile représentant le doge Loredan dans des vêtements formels sur un fond bleu clair.  Il porte un couvre-chef typique des doges de Venise. La dignité du caractère est suggérée par la fixité, le détachement solennel par le contact non-visuel avec le spectateur."/><figcaption>Portrait du Doge Leonardo Loredan par Giovanni Bellini</figcaption></figure>

### Ne confondez pas alt et title

On trouve parfois des balisages qui appliquent la même valeur à `alt` et à `title`. En général, c’est une mauvaise idée. Le texte de title, qui apparaît en pop-up, est rarement vu par les utilisateurs car il faut quelques secondes avant qu’il ne surgisse, et il ne sera pas lu par les outils d’accessibilité sauf si l’élément est en focus.

### Positionnement de alt

Les lecteurs d’écran lisent le texte de `alt` en ligne avec le reste du contenu, par conséquent il est souhaitable d’écrire le texte descriptif dans un flux contextuel, en particulier si l’image est flottée.

### Ne négligez pas les autres media

`alt` est presque exclusivement associé aux images, mais cela ne signifie pas que le texte descriptif des autres formats de media doive être négligé&nbsp;: les vidéos et les audios devraient par exemple utiliser [les sous-titres WebVTT](http://thenewcode.com/580/Make-Online-Video-Accessible-And-Searchable-With-WebVTT).

<i>Photo par <a href="https://www.flickr.com/people/bcnbits">MorBCN</a>, sous licence Creative Commons</i>.


Bien utiliser l'attribut alt


La possibilité de faire disparaître et apparaître des éléments sur une page fait partie intégrante du design responsif. Selon ce que vous voulez obtenir, il existe plusieurs façons de masquer un élément avec CSS. Dans cet article, je vais explorer les propriétés à notre disposition et les avantages et désavantages de chacune.

<h2>Les Propriétés</h2>

<h3>Display</h3>

[Comme je l’ai déjà mentionné](/articles/controler-le-modele-de-boite/), à l’intérieur d’un document HTML chaque élément est une boîte rectangulaire. Cacher un élément HTML à l’aide de la propriété `display` signifie que cette boîte rectangulaire n’est pas générée du tout.

Bien que l’élément soit toujours dans notre markup (comme vous pouvez le voir en inspectant la page), il n’existe pour ainsi dire pas dans la page. Aucune partie du modèle de boîte —&nbsp;la surface du contenu, celles du padding, de la bordure ou de la marge&nbsp;— n’est générée ou n’apparaît sur la page.

Tout contenu situé à l’intérieur de l’élément ou de ses enfants est fonctionnellement inexistant. S’il s’agit d’un élément actionnable, par exemple un bouton ou une ancre, on ne peut pas l’activer. L’élément, et tout ce qu’il contient, est également ignoré par les lecteurs d’écran.

```
.foo {
  display: none;
}
```

<figure role="group"><img src="/images/display-position-compressor.png" alt="L’élément foo disparaît et les autres éléments prennent sa place"/></figure>

<h3>Visibility</h3>

Avec la propriété `visibility`, la “boîte rectangulaire” est générée, mais elle n’est pas rendue à l’écran. Du fait que la boîte est générée, les quatre surfaces constituant la boîte affectent toujours la disposition du reste de la page, cependant sans que les quatre surfaces soient visibles à l’écran.

Mis à part le fait que la boîte soit générée, l’utilisation de la propriété visibility pour cacher un élément est semblable à la propriété display.

```
.foo {
  visibility: hidden;
}
```

<figure role="group"><img src="/images/visibility-opacity-compressor.png" alt="L’élément foo disparaît mais les autres éléments restent à leur place"/></figure>

<h3>Opacity</h3>

La propriété opacity n’a d’impact que sur la façon dont un élément apparaît visuellement —&nbsp;plus exactement sur sa transparence.

Lorsque l’opacité d’un élément est à sa valeur minimum, bien qu’il soit invisible à l’écran ses fonctionnalités demeurent, comme s’il avait une couleur solide. Par conséquent, l’élément occupe toujours son espace, il est lu par les lecteurs d’écran et on peut interagir avec lui.

```
.foo {
  opacity: 0;
}
```

<figure role="group"><img src="/images/visibility-opacity-compressor.png" alt="L’élément foo disparaît, les autres éléments restent à leur place et sont actionnables"/></figure>

<h3>Position</h3>

La propriété `position` n’est pas faite a priori pour masquer ou afficher les éléments d’une page. On l’a utilisée à cet effet parce qu’on avait besoin de cacher un élément et de le soustraire de la disposition de la page _tout en conservant la possibilité qu’il soit lu par les lecteurs d’écran et qu’il soit actionnable si besoin_.

Il y a deux manières de combiner la propriété position avec d’autres propriétés pour parvenir à cet effet.

Combiné avec les propriétés `top` et `left`, l’élément est déplacé en dehors du viewport et il est donc hors de vue.

```
.foo {
  position: absolute;
  top: -9999px;
  left: -9999px;
}
```

Une autre façon de faire, imaginée par [Jeff Burnz](http://adaptivethemes.com/using-css-clip-as-an-accessible-method-of-hiding-content), consiste à utiliser la propriété `clip` pour redimensionner la boîte rectangulaire à une taille insignifiante, ce qui la l’escamote fonctionnellement.

```
.foo {
  position: absolute;
  clip: rect(1px 1px 1px 1px); /* syntaxe pour IE6 & IE7 */
  clip: rect(1px, 1px, 1px, 1px);
}
```

Avec les deux méthodes, le résultat est identique&nbsp;:

<figure role="group"><img src="/images/display-position-compressor.png" alt="L’élément foo disparaît et les autres éléments prennent sa place"/></figure>

Bien que ces solutions relèvent un peu du bidouillage, elles sont actuellement la meilleure manière de faire disparaître un élément de l’écran tout en conservant ses fonctions.

<h3>En résumé</h3>

<table class="specificTable">  
  <thead><tr><th>&nbsp;</th><th>display</th><th>visibility</th><th>opacity</th><th>position</th></tr></thead><tbody><tr><td>Le modèle de boîte est-il généré ?</td><td><span class="checkmark red">✗</span></td><td><span class="checkmark green">✓</span></td><td><span class="checkmark green">✓</span></td><td><span class="checkmark green">✓</span></td></tr><tr><td>La boîte affecte-t-elle le layout ?</td><td><span class="checkmark red">✗</span></td><td><span class="checkmark green">✓</span></td><td><span class="checkmark green">✓</span></td><td><span class="checkmark red">✗</span></td></tr><tr><td>La boîte est-elle visible ?</td><td><span class="checkmark red">✗</span></td><td><span class="checkmark red">✗</span></td><td><span class="checkmark red">✗</span></td><td><span class="checkmark red">✗</span></td></tr><tr><td>L’élément est-il lu par les lecteurs d’écran ?</td><td><span class="checkmark red">✗</span></td><td><span class="checkmark red">✗</span></td><td><span class="checkmark green">✓</span></td><td><span class="checkmark green">✓</span></td></tr><tr><td>L’élément est-il actionnable (cliquable, focusable) ?</td><td><span class="checkmark red">✗</span></td><td><span class="checkmark red">✗</span></td><td><span class="checkmark green">✓</span></td><td><span class="checkmark green">✓</span></td></tr></tbody></table>

👉🏿 _Note complémentaire du traducteur (d'après un [article de David Walsh](https://davidwalsh.name/html5-hidden))_

HTML5 a ajouté quelques attributs intéressants comme placeholder, download et autofocus. Un autre attribut nouveau est `hidden`. Appliqué à un élément, il se comporte comme CSS `display: none;` l'élément disparaît et son espace avec, il sort du flux. Il suffit pour cela d'écrire&nbsp;:

```
<div hidden>
	Tu ne me vois plus !
</div>
```

Si un navigateur ne supporte pas cet attribut, on peut le styler via:

```
*[hidden] { display: none; }
```

Pourquoi utiliser l'attribut `hidden` ? Il est plus sémantiquement correct et devrait aider plus efficacement les lecteurs d'écran.

Pour faire réapparaître l'élément, il suffit d'utiliser la propriété `display` avec n'importe laquelle des valeurs acceptées, sauf `none`.

👉🏿 NdT : [Vincent Valentin](https://codepen.io/vincent-valentin/) a créé dans Codepen [un tableau hyper complet](https://codepen.io/vincent-valentin/full/JjGmxzV) des techniques d'escamotage (cacher, supprimer, désactiver...) et de leurs implications, à lire absolument&nbsp;!


Cacher des éléments avec CSS

Citer en HTML, un guide complet

Comme je le rappelle souvent, chaque élément de l'[arbre qui représente notre document](http://web.simmons.edu/~grabiner/comm244/weekfour/document-tree.html) (_document tree_) est [une boîte rectangulaire](/articles/controler-le-modele-de-boite/). Grosso modo, cette boîte est faite de deux sections, l'une est la boîte elle-même —&nbsp;comprenant bordures, padding et marges&nbsp;— l'autre est le contenu.



<figure role="group"><img src="/images/box-and-content-compressor.png" alt=""/></figure>

Nous pouvons contrôler la façon dont cette boîte et ses enfants sont dessinés sur la page grâce à la propriété CSS `display`. La boîte peut être placée parmi ses "soeurs" comme du texte, via `inline` et nous pouvons même lui donner le comportement d'une table via `table`.

Il n'y a que deux valeurs de la propriété `display` qui permettent à un élément de générer (ou pas) une boîte. La valeur `None` aura pour effet que ni la boîte ni son contenu ne seront affichés sur la page. La valeur `contents`, elle, aura pour effet de bien afficher la boîte _mais d'omettre totalement la boîte qui l'entoure_.

<h2>Que se passe-t-il quand on utilise display: contents&nbsp;?</h2>

Le plus simple pour le comprendre est d'imaginer qu'on a oublié les balises ouvrante et fermante de l'élément. Comme le dit [la spécification](https://www.w3.org/TR/css-display-3/#box-generation)&nbsp;:

<blockquote cite="https://www.w3.org/TR/css-display-3/#box-generation"><p>Pour ce qui est de la génération d'une boîte et de son affichage, l'élément doit être traité comme s'il avait été remplacé par son contenu dans l'arbre du document.</p>
<p><cite><a href="https://www.w3.org/TR/css-display-3/#box-generation">2.5. Box Generation: the none and contents keywords</a></cite></p></blockquote>

Prenons le balisage suivant :

```
<div class="outer">
  I’m some content
  <div class="inner">I’m some inner content</div>
</div>
```

et les styles suivants :

```
.outer {
  border: 2px solid lightcoral;
  background-color: lightpink;
  padding: 20px;
}

.inner {
  background-color: #ffdb3a;
  padding: 20px;
}
```

L'affichage attendu est :



<figure role="group"><img src="/images/draw-compressor.png" alt="la boîte inner est affichée à l'intérieur de la boîte outer"/></figure>

Mais si nous ajoutons `display: contents` à l'élément `.outer` , voici ce que nous obtenons&nbsp;:



<figure role="group"><img src="/images/display-contents-compressor.png" alt="la boîte outer a disparu, il ne reste que son contenu : I'm some content"/></figure>

Visuellement, le résultat est exactement ce que nous obtiendrions en omettant les balises ouvrante et fermante de l'élément `outer`.

```
I’m some content
<div class="inner">I’m some inner content</div>
```

<h2>Quid de... ?</h2>

Cette règle CSS, bien que simple en apparence, a quelques comportements spécifiques. Le point important à garder à l'esprit est que la règle `display: contents` n'affecte que l'affichage de la boîte, **il ne modifie en rien le balisage lui-même**.

<h3>Quid des attributs de l'élément ?</h3>

_Si, en pratique, l'élement est remplacé par son contenu, quelle est la conséquence pour ses attributs&nbsp;?_ Puisque son remplacement est pour l'essentiel purement visuel, **nous pouvons toujours sélectionner, cibler et interagir avec l'élément via ses attributs**.

Par exemple nous pouvons cibler l'élément avec son ID pour le référencer avec `aria-labelledby`:

```
<div id="label" style="display: contents;">Label here!</div>
<button aria-labelledby="label"><button>
```

Toutefois j'ai constaté que nous ne pouvons plus naviguer vers l'élément au moyen d'un [identificateur de fragment](https://fr.wikipedia.org/wiki/Identificateur_de_fragment) (_fragment identifier_)&nbsp;:

```
<div id="target" style="display: contents;">Target Content</div>

<script>
  window.location.hash = "target";
  // => Nothing happens
</script>
```

<h3>Quid des events JS ?</h3>

Comme nous venons de le voir, nous pouvons cibler un élément sur lequel a été appliqué `display: contents`. En fait, nous pouvons même cibler un élément ayant un style `display: none` mais l'event ne sera jamais déclenché parce que nous ne pouvons pas interagir avec l'élément. Cependant avec `display: contents` le contenu de l'élément étant toujours visible, nous pouvons interagir avec lui _à travers son contenu_.

Si par exemple nous appliquons un event listener pour un click sur l'élément, et que nous loggons la valeur de `this`, nous obtenons toujours l'élément extérieur (_outer_) parce qu'il existe toujours dans le document.

```
<div class="outer">I’m some content</div>

<script>
  document.querySelector(".outer").addEventListener("click", function(event) {
    console.log(this);
    // => <div class="outer"></div>
  });
</script>
```

<h3>Quid des pseudo-éléments ?</h3>

Les pseudo-éléments d'un élément auquel est appliqué `display: contents` sont considérés comme ses enfants et sont donc affichés normalement. (<span aria-hidden="true" data-icon="&#9758;"></span>&nbsp;_NdT&nbsp;: pour une intro facile aux pseudo-éléments, voir ici un article sur [les pseudo éléments css before et after](/articles/les-pseudo-elements-css-before-et-after/)_.)

```
<style>
  .outer { display: contents; }
  .outer::before { content: "Before" }
  .outer::after { content: "After" }
</style>

<div class="outer">I’m some content</div>
```

Le balisage ci-dessus donnera le résultat suivant :



<figure role="group"><img src="/images/pseudo-elements-compressor.png" alt="affichage du texte suivant : before i'm some content after"/></figure>

<h3>Quid des formulaires, images et autres éléments remplacés&nbsp;?</h3>

Les [éléments remplacés](/articles/quest-ce-quun-element-remplace/) et certains formulaires ont un comportement différent lorsqu'on leur applique `content: display`.

<h4>Les éléments remplacés</h4>

Les éléments remplacés sont des éléments dont l'apparence et les "boîtes"sont contrôlées par une ressource externe –&nbsp;c'est le cas par exemple des images. Supprimer la boîte pour de tels éléments n'a pas réellement de sens car la notion de boîte n'est pas claire les concernant. Pour ces éléments, `display: contents` fonctionne exactement comme `display: none`. Ni la boîte ni son contenu ne seront affichés.

<h4>Les formulaires</h4>

Les éléments de formulaires semblent constitués d'une simple boîte, mais sous le capot ils sont en réalité constitués de nombreux éléments. Tout comme pour les éléments remplacés, supprimer la boîte n'a pas de sens car il n'y a pas _une_ boîte. Du coup, pour les éléments de formulaires tels que `<select>`, `<input>` et `<textarea>`, `display: contents` fonctionne exactement comme `display: none`.

(Voir [la liste des éléments pour lesquels display: contents fonctionne différemment](https://www.w3.org/TR/css-display-3/#unbox-htm))

<h3>Quid des boutons et des liens ?</h3>

Les éléments `<button>` et `<a>` n'ont pas de comportement particulier avec `display: contents`. Cependant il est utile de savoir comment cette règle les affecte car cela peut ne pas sembler évident.

<h4>Les boutons</h4>

Les boutons ne sont pas constitués de boîtes, par conséquent `display: contents` ne fera que supprimer la boîte enveloppant le bouton, en ne laissant que le contenu du bouton. Si on l'utilise avec un formulaire, un clic sur ce bouton aura toujours pour effet de soumettre le formulaire et, comme nous l'avons vu, n'importe quel event listener sur le bouton fonctionnera normalement.

<h4>Les liens</h4>

La même chose s'applique aux liens, la boîte container est visuellement supprimée, ne laissant apparaître que le contenu du lien. Dans la mesure où les attributs ne sont généralement pas affectés par cette règle CSS, le lien fonctionnera toujours correctement et pourra être utilisé pour naviguer comme normalement.

<h3>Quelle est l'utilité de display: contents ?</h3>

Autrefois nous devions organiser notre HTML d'une façon qui fonctionne à la fois sémantiquement et pour notre style CSS. Cela a conduit parfois à créer trop d'éléments pour la sémantique, parfois trop peu pour le style, en particulier des éléments "frères". Ce dernier cas est particulièrement pertinent avec l'arrivée de CSS Grid Layout qui, au moins aujourd'hui, doit pouvoir travailler avec des éléments "frères".

Prenons par exemple ce layout :



<figure role="group"><img src="/images/two-layouts-compressor.png" alt=""/></figure>

Nous avons deux cartes placées côte à côte, chacune comprenant un titre, un paragraphe et un footer. Nous voulons que les sections aient la même hauteur pour toutes les cartes, indépendamment du contenu de chacune. Par exemple, la 2e carte a un titre de 3 lignes, la 1re carte a un titre de 1 ligne, mais les hauteurs de titres des deux cartes devraient être identiques.

Nous pourrions y arriver avec CSS Grid, mais pour cela il faudrait que tous les éléments dans une carte soient des "frères". Il nous faudrait organiser notre HTML comme ceci par exemple&nbsp;:

```
<div class="grid">
  <h2>This is a heading</h2>
  <p>...</p>
  <p>Footer stuff</p>

  <h2>This is a really really really super duper loooong heading</h2>
  <p>...</p>
  <p>Footer stuff</p>
</div>
```

et nous pourrions appliquer les styles suivants :

```
.grid {
  display: grid;
  grid-auto-flow: column;
  grid-template-rows: auto 1fr auto;
  grid-template-columns: repeat(2, 1fr);
  grid-column-gap: 20px;
}
```

La structuration de ce document n'est certes pas incorrecte, mais il y aurait plus de sens à regrouper chaque carte dans un élément `<article>`. C'est ici que `display: contents` entre en scène, nous donnant le meilleur des deux mondes —&nbsp;en permettant un balisage sémantique tout en permettant d'organiser notre layout .

```
<div class="grid">
  <article style="display: contents;">
    <h2>This is a heading</h2>
    <p>...</p>
    <p>Footer stuff</p>
  </article>
  <article style="display: contents;">
    <h2>This is a really really really super duper loooong heading</h2>
    <p>...</p>
    <p>Footer stuff</p>
  </article>
</div>
```

<h3>Compatibilité</h3>

Comme toujours, [la compatibilité peut être vérifiée sur CanIUse](https://caniuse.com/#feat=css-display-contents), elle est bonne aujourd'hui, à l'exception de IE.

Si vous souhaitez assurer une compatibilité maximale, vous pouvez considérer cette feature comme une amélioration progressive (_progressive enhancement_) et utiliser une solution de rechange (_fallback_) appropriée.

```
article {
  display: grid;
  grid-template-rows: 200px 1fr auto; /* e.g. Use a fixed height for the header */
}

@supports (display: contents) {
  article { display: contents; }
}
```

Comment fonctionne CSS display: contents

Comprendre WAI-ARIA, un guide complet

Créer des systèmes de menu accessibles

Des styles de listes créatifs


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](https://en.wikipedia.org/wiki/HTML5#Timeline).

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&nbsp;: 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](https://www.w3.org/TR/xhtml1/#diffs)"&nbsp;:

- 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](https://www.w3.org/TR/xhtml1/#h-4.5) 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](https://html.spec.whatwg.org/multipage/parsing.html#parsing)) :

- 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](https://meiert.com/en/blog/critical-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 :

```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)&nbsp;:

```html
<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&nbsp;: `<br>`.

En HTML vous pouvez tout écrire en majuscules :

```html
<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](https://meiert.com/en/blog/optional-html/#toc-quotes) :

```html
<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 -&nbsp;et non le XHTML-HTML&nbsp;- 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&nbsp;:

```html
<input type="text" required="required" readonly="readonly" />
```

Vous pouvez minimiser les attributs :

```html
<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&nbsp;:

```html
<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&nbsp;! (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](https://meiert.com/en/blog/the-frontend-developer-test/), et n'envoyez que du HTML valide, utilisez [le validateur du W3C](https://validator.w3.org/nu/)
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](https://meiert.com/en/blog/optional-html/#toc-tags).
   - 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](https://meiert.com/en/blog/optional-html/#toc-attribute-values).
   - N'oubliez pas que les valeurs des attributs n'ont [pas toujours besoin d'être entre guillemets](https://meiert.com/en/blog/optional-html/#toc-quotes).
   - 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](https://meiert.com/en/blog/rules-for-html/), si cela fonctionne selon le principe qu'un [poids réduit de fichier conduit également à des sites plus rapides](https://meiert.com/en/blog/html-performance/), et si cela suit l'[école du développement web minimal](https://meiert.com/en/blog/minimal-web-development/). Rien de tout cela n'est nouveau -&nbsp;notre domaine pourrait simplement décider de le redécouvrir. Des outils sont également disponibles&nbsp;: [html-minifier](https://github.com/kangax/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.


Écrire HTML à la manière HTML (pas XHTML)

Guide de l'accessibilité du clavier: HTML et CSS (1ère partie)

Guide de l'accessibilité du clavier: JavaScript (2e partie)

Introduction à RDFa, 1ère partie

Ce qu'une année à apprendre et enseigner l'accessibilité m'a appris

Au début de cette année, j'ai auto-publié un ebook intitulé _Understanding JavaScript Promises_ ([téléchargeable gratuitement](https://ebooks.humanwhocodes.com/promises)). 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](https://pagedjs.org/posts/build-a-table-of-contents-from-your-html/)", est signé Julie Blanc. Julie a travaillé sur [PagedJS](https://pagedjs.org/), 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](https://markentier.tech/posts/2021/03/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&nbsp;:

```html
<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>
      
    </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 :

```css
.toc-list,
.toc-list ol {
  list-style-type: none;
}

.toc-list {
  padding: 0;
}

.toc-list ol {
  padding-inline-start: 2ch;
}
```

[Sara Soueidan](https://www.sarasoueidan.com/) 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 :

```html
<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">
      
    </ol>
  </li>
</ol>
```

<figure class="break-out">
	<div><iframe loading="lazy" decoding="async" id="cp_embed_GRQWEox" src="//codepen.io/nzakas/embed/GRQWEox?height=450&amp;theme-id=light&amp;slug-hash=GRQWEox&amp;user=nzakas&amp;default-tab=result" scrolling="no" frameborder="0" height="450" allowtransparency="true" allowfullscreen="true" name="CodePen Embed" title="CodePen Embed" class="cp_embed_iframe " style="width: 100%; overflow: hidden;"></iframe></div>
</figure>

<div class="pen">
<img src="/images/codepen.png" alt="" class="codepen-icon"><span>voir <a href="https://codepen.io/nzakas/pen/GRQWEox">
  Table of Contents - Start</a> de Nicholas C. Zakas dans <a href="https://codepen.io">CodePen</a></span>
</div>

## 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 :

```css
.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"](https://css-tricks.com/inclusively-hidden/#screen-reader-only) pour le masquer&nbsp;:

```css
.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&nbsp;:

```html
<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">
      
    </ol>
  </li>
</ol>
```

Cette base étant posée, je suis passé à la question des lignes pointillées entre le titre et la page.

<figure class="break-out">
	<div><iframe loading="lazy" decoding="async" id="cp_embed_mdXWwmL" src="//codepen.io/nzakas/embed/mdXWwmL?height=450&amp;theme-id=light&amp;slug-hash=mdXWwmL&amp;user=nzakas&amp;default-tab=result" scrolling="no" frameborder="0" height="450" allowtransparency="true" allowfullscreen="true" name="CodePen Embed" title="CodePen Embed" class="cp_embed_iframe " style="width: 100%; overflow: hidden;"></iframe></div>
</figure>

<div class="pen">
<img src="/images/codepen.png" alt="" class="codepen-icon"><span>voir <a href="https://codepen.io/nzakas/pen/mdXWwmL">
  Table of Contents - Étape 2</a> de Nicholas C. Zakas dans <a href="https://codepen.io">CodePen</a></span>
</div>

## 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](https://www.w3.org/TR/css-gcpm-3/#leaders). 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](https://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 :

```css
.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&nbsp;? "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 :

```html
<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">
      
    </ol>
  </li>
</ol>
```

Et le CSS devient :

```css
.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.

<figure class="break-out">
	<div><iframe loading="lazy" decoding="async" id="cp_embed_ZEreyJb" src="//codepen.io/nzakas/embed/ZEreyJb?height=450&amp;theme-id=light&amp;slug-hash=ZEreyJb&amp;user=nzakas&amp;default-tab=result" scrolling="no" frameborder="0" height="450" allowtransparency="true" allowfullscreen="true" name="CodePen Embed" title="CodePen Embed" class="cp_embed_iframe " style="width: 100%; overflow: hidden;"></iframe></div>
</figure>

<div class="pen">
<img src="/images/codepen.png" alt="" class="codepen-icon"><span>voir <a href="https://codepen.io/nzakas/pen/ZEreyJb">
  Table of Contents - Étape 3</a> de Nicholas C. Zakas dans <a href="https://codepen.io">CodePen</a></span>
</div>

## 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 :

```css
.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.

<figure><img src="/images/misaligned.webp" alt=""/></figure>

Pour résoudre ce problème, j'ai réglé [`font-variant-numeric`](https://css-tricks.com/almanac/properties/f/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 :

```css
.toc-list li > a > .page {
  min-width: 2ch;
  font-variant-numeric: tabular-nums;
  text-align: right;
}
```

<figure><img src="/images/aligned.webp" alt=""/></figure>

Et voilà, la table des matières est complète !

<figure class="break-out">
	<div><iframe loading="lazy" decoding="async" id="cp_embed_rNJaeMo" src="//codepen.io/nzakas/embed/rNJaeMo?height=450&amp;theme-id=light&amp;slug-hash=rNJaeMo&amp;user=nzakas&amp;default-tab=result" scrolling="no" frameborder="0" height="450" allowtransparency="true" allowfullscreen="true" name="CodePen Embed" title="CodePen Embed" class="cp_embed_iframe " style="width: 100%; overflow: hidden;"></iframe></div>
</figure>

<div class="pen">
<img src="/images/codepen.png" alt="" class="codepen-icon"><span>voir <a href="https://codepen.io/nzakas/pen/rNJaeMo">
  Table of Contents - Final</a> de Nicholas C. Zakas dans <a href="https://codepen.io">CodePen</a></span>
</div>

## 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.

La Cascade

sémantique

Ressources complémentaires sur la sémantique HTML

Ressources complémentaires sur le web sémantique