Dispa­ri­tion du temps en HTML 5

Il semble qu’on tende à rempla­cer le projet de balise <time> par une balise géné­rique <data> en HTML 5. L’idée est de pouvoir accro­cher des micro­for­mats sur autre chose qu’une date, et leur donner une balise moins spécia­li­sée.

Sauf que, derrière, mon <time> dispa­raît, alors qu’il a un rôle bien plus natu­rel dans HTML.

Des usages

Je crois que Ian se trompe en consi­dé­rant que l’usage de <time> est unique­ment un usage d’ac­croche pour les micro­for­mats. Toute demande doit être concrète, avec des usages, alors voilà ce que j’ima­gi­nais par exemple pour <time> :

  • La possi­bi­lité d’y accro­cher une inter­face lors d’un clic sur une date, par exemple une vue calen­drier. Ce peut être en natif dans les navi­ga­teurs, par une exten­sion, ou simple­ment par javas­cript.
  • La possi­bi­lité, quand le fuseau horaire est spéci­fié, de donner la date locale équi­va­lente lors d’un survol ou d’un appel contex­tuel. Certains codes javas­cripts très lourds sont déjà utili­sés ainsi donc ce n’est pas que théo­rique.
  • Une aide à la saisie dans les éditeurs HTML, puisqu’on sait ce qu’est une date, on permet de la saisir plus simple­ment. C’est vrai pour les deux parties de la balise, celle pour les humains et celle pour les machines. On peut même imagi­ner une aide à la saisie de l’une à partir de l’autre.
  • Une aide à la vali­da­tion pour le docu­ment. Je parle autant d’une vali­da­tion tech­nique du format en véri­fiant que la date machine est bien une date valide, mais aussi pourquoi pas une vali­da­tion non offi­cielle supplé­men­taire pour regar­der le contenu humain de la balise et repé­rer quelques erreurs simples (date impos­sible, date inco­hé­rente avec la date machine spéci­fiée)
  • La possi­bi­lité de cliquer sur une date dans le navi­ga­teur pour qu’une exten­sion puisse nous donner notre agenda à cette date et peut être nous montrer des conflits, ou créer un nouvel événe­ment. Cela peut être fait en micro format mais tout n’a pas pour objec­tif d’avoir un marquage hcalen­dar. L’idée c’est de permettre à l’uti­li­sa­teur de réuti­li­ser les données même quand ce n’est pas prévu par l’au­teur.

On pourra faire certaines choses sans <time>, ce sera juste plus complexe, moins pratique, moins complet, moins géné­rique et pas aussi effi­cace. Or c’est bien pour tout ça qu’on créé des balises au lieu d’uti­li­ser plein de <span> et de <div>, non ?

De l’in­no­va­tion

Le dernier item est d’ailleurs très impor­tant parce que c’est ainsi qu’on dégage de l’in­no­va­tion. Il faut prévoir des usages dans la spec, une liberté d’en­ri­chis­se­ment par l’au­teur (les micro­for­mats), mais aussi une capa­cité de détour­ne­ment et d’in­no­va­tion par le lecteur et les navi­ga­teurs.

Ça demande une capa­cité de repé­rer les struc­tures et formats de base d’un docu­ment, ici les dates. Peut être que rien ne s’en déga­gera d’im­por­tant, mais la capa­cité de pouvoir faci­le­ment indi­vi­dua­li­ser les dates comme dates et pas que comme « donnée » me paraît néces­saire pour pouvoir ensuite les recher­cher et mani­pu­ler avec javas­cript.

Marquer les dates est d’au­tant plus perti­nent dans cette optique que c’est un type de donnée extrê­me­ment riche et complexe, avec de plus des usages très spéci­fiques pour l’homme : diffé­rentes syntaxes, diffé­rents calen­driers, déca­lages horaires, chan­ge­ments d’heures, liai­sons avec les agen­das, durée rela­tive à partir de l’heure actuelle, etc. S’il y avait un type qui méri­tait vrai­ment d’avoir sa balise, c’était clai­re­ment celui là.

De la spécia­li­sa­tion

Mon code javas­cript et mon navi­ga­teur ne peuvent rien en faire tel quel. La balise ne donne aucune infor­ma­tion ni sur le rôle, ni sur le type, ni sur la syntaxe de la donnée. Tous les usages dépendent d’un micro­for­mat externes et non norma­lisé dans HTML. On aurait utilisé un <span> avec un attri­but data-value que ça aurait eu autant de signi­fi­ca­tion du point de vue des acteurs HTML. Ce <data>, tel quel, ne sert simple­ment plus à rien.

Une partie de ce problème pour­rait dispa­raître si on ajou­tait en plus un attri­but « type » au <data>, mais quel avan­tage aurait-on ? Tout ingé­nieur cherche à avoir du géné­rique, mais parfois ce n’est simple­ment pas ce qu’il y a de mieux. Qui a pesté en javas­cript ou en CSS au moins une fois parce que ces foutus boutons de formu­laire avaient le même nom de balise que les cases à cocher, lignes de texte et autres champs de formu­laires ? On cherche plus souvent à les indi­vi­dua­li­ser malgré ce nom de balise commun qu’à les regrou­per grâce à cette même géné­ri­cité.

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éel­le­ment avan­tage à fusion­ner toutes les données de type diffé­rent en un <data>. Une balise géné­rique avec des attri­buts spéci­fiques c’est juste plus complexe, et à mani­pu­ler en code, et à écrire pour les auteurs. Si je pousse la logique on pour­rait aussi avoir un <p type=title> ou un <div type=article>. En cari­ca­tu­rant un <tag type=p role=title>. Un <data> ne suit aucune logique et aucune leçon du passé de HTML.

À la limite, n’au­rait-on pas mieux fait d’ajou­ter un attri­but géné­rique machineval à toutes les balises pour leur propo­ser un contenu alter­na­tif ? Pour le coup ça aurait eu le mérite de la géné­ri­cité et ça aurait permis d’ima­gi­ner beau­coup d’usages inno­vants. Le besoin des micro­for­mats à l’ori­gine de <time> et de <data> était d’ailleurs celui là.

<time> était simple, compré­hen­sible et compris immé­dia­te­ment par les auteurs, utili­sable, utile et dors et déjà utilisé. Quelle idée a-t-on eu de le rempla­cer par une balise qui n’a aucune de ces quali­tés ?

Ceci n’em­pêche toute­fois pas d’avoir un <data> à côté pour les autres types de données, même si person­nel­le­ment j’ai du mal à en voir la valeur ajou­tée hors micro­for­mat ou le besoin de cette balise pour les micro­for­mats (les attri­buts data-* font très bien l’af­faire pour le besoin exprimé).

9 commentaires

  1. 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’attribut value) 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? Attributs data-* 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 le value 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’attribut href 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 attribut item* 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.

    Répondre

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

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

    3. 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é.

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

    Répondre

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

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

    Répondre

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *