Il semble qu’on tende à remplacer le projet de balise <time>
par une balise générique <data>
en HTML 5. L’idée est de pouvoir accrocher des microformats sur autre chose qu’une date, et leur donner une balise moins spécialisée.
Sauf que, derrière, mon <time>
disparaît, alors qu’il a un rôle bien plus naturel dans HTML.
Des usages
Je crois que Ian se trompe en considérant que l’usage de <time>
est uniquement un usage d’accroche pour les microformats. Toute demande doit être concrète, avec des usages, alors voilà ce que j’imaginais par exemple pour <time>
:
- La possibilité d’y accrocher une interface lors d’un clic sur une date, par exemple une vue calendrier. Ce peut être en natif dans les navigateurs, par une extension, ou simplement par javascript.
- La possibilité, quand le fuseau horaire est spécifié, de donner la date locale équivalente lors d’un survol ou d’un appel contextuel. Certains codes javascripts très lourds sont déjà utilisés ainsi donc ce n’est pas que théorique.
- Une aide à la saisie dans les éditeurs HTML, puisqu’on sait ce qu’est une date, on permet de la saisir plus simplement. C’est vrai pour les deux parties de la balise, celle pour les humains et celle pour les machines. On peut même imaginer une aide à la saisie de l’une à partir de l’autre.
- Une aide à la validation pour le document. Je parle autant d’une validation technique du format en vérifiant que la date machine est bien une date valide, mais aussi pourquoi pas une validation non officielle supplémentaire pour regarder le contenu humain de la balise et repérer quelques erreurs simples (date impossible, date incohérente avec la date machine spécifiée)
- La possibilité de cliquer sur une date dans le navigateur pour qu’une extension puisse nous donner notre agenda à cette date et peut être nous montrer des conflits, ou créer un nouvel événement. Cela peut être fait en micro format mais tout n’a pas pour objectif d’avoir un marquage hcalendar. L’idée c’est de permettre à l’utilisateur de réutiliser les données même quand ce n’est pas prévu par l’auteur.
On pourra faire certaines choses sans <time>
, ce sera juste plus complexe, moins pratique, moins complet, moins générique et pas aussi efficace. Or c’est bien pour tout ça qu’on créé des balises au lieu d’utiliser plein de <span>
et de <div>
, non ?
De l’innovation
Le dernier item est d’ailleurs très important parce que c’est ainsi qu’on dégage de l’innovation. Il faut prévoir des usages dans la spec, une liberté d’enrichissement par l’auteur (les microformats), mais aussi une capacité de détournement et d’innovation par le lecteur et les navigateurs.
Ça demande une capacité de repérer les structures et formats de base d’un document, ici les dates. Peut être que rien ne s’en dégagera d’important, mais la capacité de pouvoir facilement individualiser les dates comme dates et pas que comme « donnée » me paraît nécessaire pour pouvoir ensuite les rechercher et manipuler avec javascript.
Marquer les dates est d’autant plus pertinent dans cette optique que c’est un type de donnée extrêmement riche et complexe, avec de plus des usages très spécifiques pour l’homme : différentes syntaxes, différents calendriers, décalages horaires, changements d’heures, liaisons avec les agendas, durée relative à partir de l’heure actuelle, etc. S’il y avait un type qui méritait vraiment d’avoir sa balise, c’était clairement celui là.
De la spécialisation
Mon code javascript et mon navigateur ne peuvent rien en faire tel quel. La balise ne donne aucune information ni sur le rôle, ni sur le type, ni sur la syntaxe de la donnée. Tous les usages dépendent d’un microformat externes et non normalisé dans HTML. On aurait utilisé un <span>
avec un attribut data-value
que ça aurait eu autant de signification du point de vue des acteurs HTML. Ce <data>
, tel quel, ne sert simplement plus à rien.
Une partie de ce problème pourrait disparaître si on ajoutait en plus un attribut « type » au <data>
, mais quel avantage aurait-on ? Tout ingénieur cherche à avoir du générique, mais parfois ce n’est simplement pas ce qu’il y a de mieux. Qui a pesté en javascript ou en CSS au moins une fois parce que ces foutus boutons de formulaire avaient le même nom de balise que les cases à cocher, lignes de texte et autres champs de formulaires ? On cherche plus souvent à les individualiser malgré ce nom de balise commun qu’à les regrouper grâce à cette même généricité.
De la même manière qu’on n’a pas que <object>
mais bien <video>
<img>
et <audio>
, il n’y a pas réellement avantage à fusionner toutes les données de type différent en un <data>
. Une balise générique avec des attributs spécifiques c’est juste plus complexe, et à manipuler en code, et à écrire pour les auteurs. Si je pousse la logique on pourrait aussi avoir un <p type=title>
ou un <div type=article>
. En caricaturant un <tag type=p role=title>
. Un <data>
ne suit aucune logique et aucune leçon du passé de HTML.
À la limite, n’aurait-on pas mieux fait d’ajouter un attribut générique machineval
à toutes les balises pour leur proposer un contenu alternatif ? Pour le coup ça aurait eu le mérite de la généricité et ça aurait permis d’imaginer beaucoup d’usages innovants. Le besoin des microformats à l’origine de <time>
et de <data>
était d’ailleurs celui là.
<time>
était simple, compréhensible et compris immédiatement par les auteurs, utilisable, utile et dors et déjà utilisé. Quelle idée a-t-on eu de le remplacer par une balise qui n’a aucune de ces qualités ?
Ceci n’empêche toutefois pas d’avoir un <data>
à côté pour les autres types de données, même si personnellement j’ai du mal à en voir la valeur ajoutée hors microformat ou le besoin de cette balise pour les microformats (les attributs data-*
font très bien l’affaire pour le besoin exprimé).
9 réponses à “Disparition du temps en HTML 5”
Pas d’accord sur la plupart des points. Je ne suis pas spécialement pour la suppression de
<time>
, mais l’introduction d’un élément<data>
me semble utile.Commençons par
<data>
. Même si la motivation principale est une utilisation par des microformats ou avec microdata, je l’associe pour ma part au mécanisme des data-attributes avec une subtilité importante:1. Les data-attributes permettent d’ajouter sur un élément une donnée textuelle arbitraire, simple et de format libre, pour en faire à peu près ce qu’on veut, essentiellement pour du scripting.
2. L’élément
<data>
fournit un mécanisme similaire, avec comme subtilité que l’information est unique (valeur de l’attributvalue
) et représente un équivalent technique de la valeur textuelle de l’élément. C’est utile quand on détient une information avec à la fois une représentation en langage courant et une représentation technique, et qu’on avoir ces deux représentations dans le DOM (une visible et l’autre exploitable par des scripts).Dans l’absolu, pour ce cas d’usage on peut faire sans l’élément
<data>
, et se contenter d’un data-attribute. Il faudra alors documenter le fait que pour un projet précis, dans tel cas de figure, le contenu de l’attribut*data-value
,*data-equiv
, ou encore*data-tartiflette
est la représentation technique du contenu texte de l’élément, et faire de la pédagogie en interne pour que ça soit utilisé tel quel par les développeurs. Avec un élément<data>
qui standardise ce mécanisme syntaxique, par contre, on peut se reposer sur une spécification et des contenus pédagogiques génériques, et c’est la spec qui joue le rôle de convention de codage. Moi je trouve ça pas mal.Donnée technique correspondant au contenu texte? Élément
<data>
. Besoins plus spécifiques, données multiples? Attributsdata-*
custom.Il est vrai que l’élément
<data>
ne qualifie pas son contenu. Il aurait peut-être été préférable de créer un attribut global qui joue le même rôle que levalue
de l’élément<data>
, disons un attribut*equiv
juste pour le fun. Mais en pratique ça aurait créé des conflits avec des éléments existants qui utilisent déjà un mécanisme de correspondance entre le contenu texte et un attribut principal (par exemple l’attributhref
sur<a>
). Il aurait alors fallu créer un attribut semi-global (utilisable globalement sauf sur la liste d’éléments suivante: …). Pas sûr que ça aurait été beaucoup plus élégant ou clair.Au final je trouve l’élément
<data>
plutôt sympa. Les UAs ne vont pas pouvoir en faire grand chose mais on s’en fiche, comme pour les data-attributes c’est pas le but!Quant au cas d’usage avec les mécanismes d’extension sémantique, il me semble très pertinent. Utiliser
<meta>
pour ça (actuellement recommandé par les exemples de microdata) n’est pas terrible, ça perturbe les auteurs qui ont l’habitude de confiner<meta>
à l’élément<head>
. Utiliser un nouvel attributitem*
fonctionnerait uniquement pour microdata, tandis qu’utiliser des data-attributes fonctionnerait uniquement pour les microformats… ici, avec<data>
, on a une solution simple qui marche pour les deux, et ça c’est cool.Je n’accroche pas avec ta différenciation entre la balise data et les attributs data-*. L’idée d’avoir un attribut propre pour la représentation machine est bonne, mais à l’unique condition que cette représentation soit connue. Ici la balise data ne nous dit pas si c’est une date, un nombre, une quantité, ou quoi que ce soit d’autre. Au final je suis désolé mais pour le navigateur ou un client HTML générique ça n’a pas plus de sens qu’un attribut data-*.
En gros tu dis au client « attention, ici c’est une donnée importante qui n’est là que pour toi » et juste en même temps « ah mais non, je ne te dirai pas comment la relire ni comment l’interpréter ». Quel est la valeur ajoutée ?
C’est d’ailleurs bien ce que je reproche à la disparition de la balise time. Pour cette dernière le client HTML savait que la représentaiton machine était une date, et pouvait commencer à manipuler (ou non) la donnée.
Ici, le sens n’est pris que par le microformat qui est derrière, et donc autant que ce microformat s’occupe aussi de l’attribut et de la forme de la donnée en data-*. Il n’y a aucun avantage visible à avoir une balise au niveau HTML (du moins je ne le vois pas et tu n’en donnes aucun).
Après que ce soit une balise meta, une balise data ou un attribut data-* ne change pas grand chose, mais qu’on ne vienne pas me dire que time spécialise trop le langage alors que de l’autre côté on ajoute une balise qui n’a aucun sens utilisable et contient une donnée machine dont on ne connait ni le format ni le type.
En fait tu dis «data n’est pas un mécanisme sémantique pertinent», et c’est vrai. Parce que data est un mécanisme syntaxique, pas un mécanisme sémantique.
Le fait est que ce mécanisme syntaxique n’existe pas en dehors de
<data>
. Que les microformats/microdata en ont besoin. Et enfin je pense que ça peut être utile de manière générale pour du scripting (même si les data-attributes pourraient suffire). Rien de plus à dire: c’est pas con, ça va servir, the end.Mais non mais non. Ce n’est même pas syntaxique, rien ne définit qu’il s’agit forcément d’une date. On ne sait rien justement.
Et non, je ne vois pas le « besoin ». Je n’ai vu aucun avantage par rapport à un data-*. Aucun, même pas plus simple finalement.
Quant à l’utiliser pour du scripting, là aussi, tant qu’on n’y accroche pas plus d’information, qu’elle soit sémantique ou technique, je ne vois aucune différence avec un data-*. Même du point de vue « c’est standard », c’est même presque négatif parce qu’un attribut standard fourre tout (donc qui n’a plus aucune utilité propre) c’est pire que plusieurs standards « de fait » distincts mais spécialisés.
Après je ne suis pas contre data hein, ça me parait inutile mais ce qui m’agace c’est uniquement qu’on utilise ça en remplacement de time, qui lui avait une utilité.
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’attributpubdate
. 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é avecfor
/id
. Mais je n’y tiens pas absolument.Que time soit un cas particulier de data nous sommes d’accord.
Que pas mal des usages décrits puissent être faits (plus difficilement) sans balise time, nous sommes aussi d’accord. Notes juste que c’est vrai aussi pour data. Tout ce que fait la balise data peut être fait en data-*. De toutes façons dès qu’on utilise de la programmation derrière tout peut toujours être fait, c’est juste plus ou moins complexe.
Maintenant partie des usages décrits je les ai déjà vus. J’ai déjà vu des libs javascript qui tentent plus ou moins facilement de jouer avec les décalages horaires dans les dates de publication, des extensions qui permettent (mal) de repérer des dates pour faire une liaison avec google calendar, des libs javascript qui tentent d’interpréter les dates pour en donner une présentation adaptée et dynamique, etc.
Que tu y crois ou pas, que j’y crois ou pas, ce qui m’intéresse c’est juste de noter que la date, contrairement à beaucoup d’autres types de données, est suffisamment significative, riche et complexe, pour qu’on puisse avoir envie de la signifier en langage machine, et donc d’y accrocher des comportements. Il ne m’appartient pas de juger de ce qui en sera fait ou pas derrière, juste de me rendre compte que ça peut être utile.
Pour ce qui est du nombre de balise inutile, comme je disais plus haut, « time » peut finalement avoir une utilisation limitée, mais factuellement « data » ne sert à rien sans microformat par dessus (et s’il y a microformat pour comprendre le sens et la syntaxe, standardiser la balise et l’attribut dans HTML n’a aucune utilité).
Pour moi c’est du même niveau que object/video/img. On peut certes avoir une balise générique mais si ça veut dire faire perdre au client l’information de comment il faut la relire et ce qu’elle représente, alors on perd tout l’intérêt.
Ici on avait une balise simple, facile à utiliser, et qui offrait plein d’opportunités. Les gens ne s’y sont pas trompés parce qu’elle était déjà utilisée. Ce genre de balises sont rares dans HTML, qui comme tu le dis a plein de trucs à l’utilisation douteuse. C’est juste idiot d’avoir jeté celle là.
S’il faut une balise data, alors ajoutons au moins deux attributs : un type (nombre, date, etc.) et une unité (kg, octets, etc.), quitte à ne spécifier que le premier et à laisser le second assez libre. Ceci dit ça va être complexe et mal utilisé (erreurs, mauvaises interprétations) alors que time ne faisait pas débat.
En fait je me rends compte que j’ai été long et que j’ai pas mal parlé mais qu’il y a défi simple à faire :
– Qui me trouve une utilisation de la balise data qui ne demande pas une spécification microformat/data à côté pour éclaircir le type, le sens et la syntaxe de l’attribut value ?
– En considérant donc qu’il y a une spécification microdata/format associée, qui me trouve une utilisation qui soit plus complexe si on laissait à la spec microformat/data le soin de spécifier l’attribut data-* utilisé ?
Personnellement je n’ai trouvé aucune réponse à ces deux questions, et personne ne m’en a donné. À l’inverse, quand bien même certains usages existent déjà (ils en sont simplement simplifiés) et d’autres sont discutables, je vois pas mal de choses que ça rend techniquement possible ou plus simple avec la balise time.
Voilà, c’est peut être dit plus simplement et rapidement ainsi.
Certains le disent mieux que moi, aussi je vous laisse lire http://lists.w3.org/Archives/Public/public-html/2011Oct/0163.html
J’ai l’impression de retrouver tous mes points vis à vis de la balise time.
Youpie! https://twitter.com/stevefaulkner/status/130992360158007296