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.