Deuxième partie: l’élément <time> et la granularité de la spécificité sémantique en HTML.

À partir du moment où on a un élément <data> qui fonctionne comme décrit ci-dessus, on peut considérer <time> comme un cas particulier de <data>, avec une sémantique qui qualifie son contenu (à la fois le texte et la valeur machine). Ce qui permet théoriquement à une UA de faire plein de choses avec ce contenu.

Tu proposes tout un tas de cas d’usage mais je dois avouer que je ne suis pas du tout convaincu. Ceux qui reposent sur des fonctionnalités d’applications web peuvent être faits avec ou sans élément <time> dans la spec. Ceux qui reposent sur l’UA sont de la fiction et je n’ai vue aucune velléité de faire quoi que ce soit avec <time> côté UA. Si des implémentations débarquent dans les UA ça sera sans doute sur des choses un peu plus complètes et utiles, à base de microformats/microdata.

Dans l’absolu j’aurais bien conservé <time> malgré tout car:
– C’est un élément simple à comprendre, et déjà un peu utilisé.
– Les exploitations directes par les UAs me semble très peu probables, mais pourquoi pas laisser cette possibilité au cas où.
– Les dates et heures sont des informations suffisamment courantes dans les contenus, y compris et surtout dans des contenus typés extraits de bases de données, pour légitimer un élément dédié.

À l’inverse il y a deux-trois éléments HTML à la sémantique spécifique que je virerais bien de la spec. On a déjà réussi à virer <acronym> (cas particulier de <abbr>), et les velléités d’ajouter un élément <dialog> (héritage d’un exemple foireux d’utilisation de <dl> dans la spec HTML4) n’ont heureusement rien donné. Je virerais bien l’élément <address> (qui ne désigne pas ce qu’on appelle couramment une «adresse») pour compléter le tableau.

En dehors du détail des cas particuliers, il y a évidemment la question du degré de spécificité en sémantique HTML. Et là c’est assez simple: HTML propose très peu d’éléments pour décrire la nature des contenus textuels. Il y a des tentations de rajouter des cas particuliers dans la spec (<dialog>…), heureusement battues en brèche la plupart du temps. Pour ma part je trouve ça assez sain cette sémantique très réduite: ça rend le langage plus accessible, ça évite des gaspillages de productivité énormes dans la sur-sémantisation à outrance (même si beaucoup arrivent à sur-sémantiser quand même avec très peu d’éléments). Je préfère avoir 30 ou 50 éléments pour décrire le texte que 150.

À partir de cette base sémantique finalement très générique (et donc à la fois versatile et peu exploitable par les UAs), on peut étendre la sémantique de HTML pour répondre à des besoins spécifiques. Le W3C a tenté ça avec un passage au HTML extensible (XHTML), ça n’a pas pris. Le WHATWG tente le coup avec microdata qui rationalise un peu des principes utilisés dans les microformats, et on verra bien ce que ça donne. Moi ça me semble plutôt sain de ne pas créer (ou même parfois conserver) des éléments sémantiques juste parce que potentiellement les UA pourraient les parser et en faire quelque chose.

Tu argumentes par l’absurde en disant que si on veut être générique, on peut faire *<tag type="paragraph"> au lieu de <p>. On peut aussi argumenter par l’absurde en disant que si on veut être spécifique, on peut faire <prose><p><word><letter type="latin-capital">L</letter>… ou encore créer des éléments de type «image» différents suivant la nature de l’illustration ou ajouter des éléments sémantiques pour décrire finement les nuances de discours. J’ai peur que le raisonnement par l’absurde ne nous mène nulle part.

Bon, si ça n’en tenait qu’à moi j’aurais bien gardé l’élément <time> (en plus de <data>), en particulier pour son usage en combinaison avec <article> et l’attribut pubdate. J’aurais même aimé avoir un élément *<author> permettant d’indiquer l’auteur (ou les auteurs, en utilisant plusieurs éléments) d’un contenu donné: <blockquote> ou <article> en amont dans le DOM, ou un élément précis identifié avec for/id. Mais je n’y tiens pas absolument.