Discussion :

[Nolan Lawson]

L'élément <time> devrait en fait faire quelque chose, par Nolan Lawson

Un modèle d'interface utilisateur courant ressemble à ceci :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Post published 4 hours ago

Les gens font beaucoup de choses avec cette mention « il y a 4 heures ». Ils peuvent en faire un lien permanent :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Post published <a href="/posts/123456">4 hours ago</a>

Ou ils peuvent lui attribuer une info-bulle pour afficher la date et l'heure exactes au survol/focus :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Post published
<Tooltip content="December 14, 2025 at 11:30 AM PST">
  4 hours ago
</Tooltip>

Remarque : je pars du principe que vous utilisez un composant Tooltip écrit dans votre framework préféré, par exemple React, Svelte, Vue, etc. Il existe également le popover="hint" et l'API Interest Invokers, qui nous permettraient de le faire de manière succincte en HTML/CSS natif.

Si vous êtes un puriste du HTML (comme moi), vous pouvez utiliser l'élément <time> :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Post published
<time datetime="2025-12-14T19:30:00.000Z">
  4 hours ago
</time>

C'est génial ! Nous disposons désormais d'un moyen sémantique pour exprimer l'horodatage exact d'une date. Les navigateurs et les lecteurs d'écran devraient donc l'utiliser et nous permettre d'éviter ces infobulles manuelles ennuyeuses et... oh, attendez, non. L'élément <time> ne fait pratiquement rien.

J'ai fait quelques recherches à ce sujet et je n'ai trouvé aucun navigateur ou technologie d'assistance qui utilise réellement l'élément <time>, à part, bien sûr, pour l'afficher. (Ouf !) Et ce, malgré le fait que <time> soit utilisé dans environ 8 % des chargements de pages selon le suivi d'utilisation de Chrome.

Mise à jour : Léonie Watson nous informe que les lecteurs d'écran NVDA et Narrator lisent effectivement l'horodatage dans un format lisible par l'homme ! <time> a donc un impact sur l'accessibilité (même si celui-ci n'est sans doute pas positif).

Alors, à quoi sert réellement <time> ? D'après ce que je peux en juger, il est utilisé par les moteurs de recherche pour afficher des extraits de date dans les résultats de recherche. Cependant, je ne trouve aucune directive de Google qui préconise spécifiquement l'élément <time>, bien qu'il existe un article de 2023 du Search Engine Journal qui cite un représentant de Google Search :

Google ne se base pas sur un seul facteur de date, car tous les facteurs peuvent être sujets à des problèmes. C'est pourquoi nos systèmes examinent plusieurs facteurs afin de déterminer la meilleure estimation possible de la date de publication ou de mise à jour significative d'une page.

En fait, la seule documentation Google que j'ai trouvée ne mentionne pas du tout <time>, mais recommande plutôt d'utiliser les champs datePublished et dateModified de Schema.org. (C'est-à-dire, pas même HTML.)

Voilà donc où nous en sommes. <time> est une idée intéressante en théorie, mais dans la pratique, elle semble être une promesse non tenue du HTML sémantique. Un article de CSS Tricks publié en 2010 contient une excellente citation de Bruce Lawson (sans lien de parenté) à ce sujet :

Les utilisations de dates sans ambiguïté dans les pages web ne sont pas difficiles à imaginer. Un navigateur pourrait proposer d'ajouter des événements au calendrier d'un utilisateur. Un navigateur localisé en thaï pourrait proposer de transformer les dates grégoriennes en dates de l'ère bouddhiste thaïlandaise. Un navigateur japonais pourrait localiser 16:00 en « 16:00時 ».

Ce serait formidable, et j'aimerais beaucoup voir les navigateurs et les lecteurs d'écran utiliser <time> de cette manière. Mais pour l'instant, il s'agit plutôt d'une relique inerte des débuts du HTML5. Je continuerai toutefois à l'utiliser, car (comme dirait Marge Simpson), je trouve simplement que c'est génial.

Source : "The <time> element should actually do something"

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

Tout le monde connaît votre emplacement : me localiser grâce aux publicités dans les applications, par Tim

Ne devinez pas ma langue : Si vous utilisez encore la géolocalisation IP pour déterminer la langue à afficher, arrêtez de perdre votre temps, par Robert Vitonsky

[CosmoKnacki]

À mon avis, l'idée du web sémantique c'est éteinte lorsqu'on a préféré se tourner vers html5 plutôt que de partir de xhtml pour le faire évoluer.

Dans la décennie 2000-2010, la situation était plus claire. Le tout-venant se faisait en html4, et le professionnel se tournait vers xhtml 1.0 strict (ce qui obligeait à une certaine rigueur, lui procurait un moyen de vérification avec des outils de validation, et une estime, en partie supposée, des moteurs de recherche).
Pour étendre la capacité d'expression du nombre limité de balises du xhtml, plusieurs systèmes d'attributs (concurrents) ont été inventés dans cette quête du web sémantique. Mais malheureusement, ceux ci ne semblent pas avoir servi d'inspiration pour la creation d'une nouvelle version du xhtml.

Puis vint le html5, qui, il faut bien le dire, à le cul entre deux chaises:

• il introduit des balises idoines comme par exemple nav
• mais on dirait un peu un pansement sur une jambe de bois
• au final il semble bien se moquer de l'aspect sémantique
• à sa décharge, il est quand même allé de l'avant
• mais quelle évolution depuis lors

.

Bref, à mon avis, l'abandon du xhtml et de ses perspectives d'évolutions est une énorme bêtise.

(J'avoue que c'est une vision un peu raccourcie des choses, mais c'est mon sentiment sur le sujet).