Malheureusement, il y a eu un certain nombre d'inquiétudes dans la manière dont hCalendar utilise le patron de structure "abréviation". Cela utilise l'élément HTML "abbr" pour ajouter les données logicielles aux pages. Nos inquiétudes étaient :
- l'impact chez les utilisateurs non-voyant qui utilisent des lecteurs d'écran configurés pour lire la forme développée des abréviations, lorsque ces formes développées sont les données logicielles
- l'impact chez les utilisateurs mal-voyant qui utilisent des lecteurs d'écran où les info-bulles des abréviations conçues pour les logiciels seraient lues
- l'impact des info-bulles incompréhensibles chez les utilisateurs présentant des déficiences intellectuelles
- la restriction potentielle des abréviations aux domaines qui en ont besoin (voyage - code aéroport, finance - code ticker, etc)
En attendant que ces problèmes soient corrigés, les normes de marquage sémantique de la BBC ont été mises à jour afin d'empêcher l'utilisation de texte non destiné aux humains dans les abréviations. [...] Pour cette raison, nous avons pris la décision de supprimer le microformat hCalendar de /programmes jusqu'à ce que :
- le "BBC accessibility group" continue ses tests et déclare que cette utilisation des abréviations peut être utilisée sans risque
- ou que la communauté des microformats se mette d'accord sur une alternative accessible du patron de structure "abréviation". Une conversation à ce propos a déjà été commencée par Frances Berriman.
Alors, quel est le problème ? En HTML, tout est texte, car le but du HTML est de présenter des documents aux humains. Puis est venu un temps où le HTML n'était plus seulement une expression d'un document, mais était le document lui-même, et où on a voulu exploiter de manière automatisées les informations fournies dans ces documents. De là est née la "communauté" des microformats (ou µformat). Le but des microformats (et d'autres initiatives comme RDFa) est de mettre dans un seul et même document les informations pour l'humain et pour le logiciel. Et dans cet objectif, les microformats ont une approche prag-ma-ti-que, dans le sens où c'est la réponse que vous donnera systématiquement un microformateux à n'importe laquelle de vos questions (j'exagère, ils ont aussi une deuxième réponse : "tous des cons").
Pour mélanger des données calendaires destinées à être vues par des humains et des logiciels, il existe le microformat hCalendar, basé sur iCalendar, lui-même basé sur vCalendar (le v de vCalendar venant de Versit, le i de iCalendar étant pour internet, le h de hCalendar étant pour... HTML évidemment, vu que la description du format énonce "suitable for embedding in HTML or XHTML, Atom, RSS, and arbitrary XML", donc c'est pragmatique). En hCalendar, on représente une date de la façon suivante :
à <abbr class="dtstart" title="20080624T12:15:10+0200">midi et quart le 24</abbr>.
Ce qui sera affiché de la façon suivante :
à midi et quart le 24.
Le problème est que cet élément <abbr> a un sens en HTML : représenter une abréviation, avec la forme développée de l'abréviation dans l'attribut "title" de l'élément, par exemple : ex.. Et les navigateurs cherchent à afficher cette information. Pour les voyants, cela ne se déclenche en général qu'au passage de la souris au-dessus du texte concerné, pour les déficients visuels, le problème peut être tout autre, d'où l'arrêt de l'utilisation de cette technique sur le site web de la BBC.
Alors, quelles solutions ? Dans les commentaires, Lachlan Hunt propose d'utiliser l'élément time défini dans HTML5. HTML5, c'est le standard encore à l'état d'ébauche pour remplacer HTML 4 et les XHTML... Pour cela, ils réinventent un nouveau format de temps, et ils réinventent un algorithme de conversion d'une date en un format textuel. Mais ils réinventent cela de manière prag-ma-ti-que (ça vous rappelle d'autres personnes ?). D'ailleurs on trouve dans les petites notes associées à cet élément :
Les cas d'utilisation primaires pour ces éléments sont de marquer des dates de publication, par exemple dans les billets de blogs, et pour les dates d'événements en marquage hCalendar.
Oui, le web, c'est pragmatique. Mais ni HTML5 ni hCalendar ne sont des standards supportés à l'heure actuelle, ce qui ne fait que tourner les choses en rond.
Une approche que je n'ai pas vu citée est celle prise dans VXML, et en particulier l'élément say-as issu de SSML. En SSML, on laisse le navigateur vocal interpréter certaines données. Si l'on prend les valeurs possibles pour says-as, notre exemple précédent revient à écrire :
à <say-as interpret-as="time" format="hms24">12:15:00</abbr> le <say-as interpret-as="date" format="d">24</abbr>.
Ca ne convient évidemment pas directement dans notre exemple, vu qu'on perd des informations (année, mois) ainsi que la liaison entre la date et l'heure, mais il est à noter que cette approche dans laquelle le navigateur interprète des attributs de l'élément pour interpréter le contenu n'est pas présente en HTML.
Une autre réaction est celle de "Cochons sur l'aile" qui pointe une discussion sur IRC précisant que la BBC n'est pas pragmatique, car l'utilisation d'"abbr" n'est pas rendue obligatoire par hCalendar (ce qui nous renseigne sur la clarté et la précision du "standard" hCalendar), et c'est (presque) ce qui est dit dans la page de description du patron de structure "abréviation" :
Notez que les exemples suivant sont tous équivalents pour un interpréteur microformat :<span class="dtstart">20070501</span> ⇒ 20070501 <span class="dtstart">2007-05-01</span> ⇒ 2007-05-01 <abbr class="dtstart" title="20070501">1er mai 2007</abbr> ⇒ 1er mai 2007
On a donc le choix entre un <abbr> inaccessible, ou un <span> illisible. Une autre proposition est faite, dans la discussion référencée plus haut :
à <span class="dtstart"><span class="hour">12</span> et <span class="minutes">15</span> le <span class="day">24</span></span>à 12 et 15 minutes le 24
On voit tout de suite que cette solution ne convient pas non plus, car on perd la possibilité de représenter les éléments de manière textuelle (par exemple, on doit marquer "12" et pas "midi"), et on a perdu des informations (année, mois). Cette solution est donc très loin d'être satisfaisante, finalement la BBC n'est pas si a-pragmatique que ça.
Dans les réactions à cette annonce, greut signale la réaction d'Edd Dumbil à la réaction de John Resig (un gourou de Javascript travaillant chez Mozilla Corp, qui en est resté à Windows 98 en ce qui concerne la gestion de la sécurité applicative). John Resig nous dit à propos de RDFa :
Criblé de terminologie avancée, voire même complètement embrouillante (espace de nommage XML, Dublin Core, web sémantique, sans oublier de mentionner de nombreux nouveaux attributs - comme typeof, about et property) il apparaît être solidement encerclé dans les contraintes dont les microformats ont réussi à se libérer, leur permettant d'arriver à une adoption généralisée.
En fait RDFa définit en tout et pour tout 5 nouveaux attributs (about, property, resource, datatype, typeof) ; Dublin Core est le vocabulaire de base pour annoter une publication (on y retrouve la notion d'auteur, de date de publication, etc...), normalisé (ISO, ANSI, IETF...), utilisé par exemple dans RSS-RDF, RSS 2.0 (mais pas Atom, le pragmatisme impliquant de réinventer la roue)... donc si John n'y comprend rien, ça ne l'empêche pas de l'utiliser sur son blog. Les espaces de nommages XML ça l'embrouille aussi... c'est dommage, vu que les espaces de nommage en Javascript sont un de ses cheval de bataille dans jQuery vs. le monde. Et pour le web sémantique... soyons gentils, passons. Vous l'aurez compris, John est un prag-ma-ti-que... enfin quand il s'agit de taper sur les non-pragmaticiens, parce que dans jQuery, il a fait des choses totalement non pragmatiques, comme le support de la syntaxe des sélecteurs CSS3 et d'une partie de XPath : quelle erreur pour un pragmaticien de faire référence à un existant, ça fait toute une terminologie avancée, voire même complètement embrouillante, à acquérir.
