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é).
Laisser un commentaire