Emily nous encourage dans le dernier billet de sa série à implémenter le « modèle-de classe-value ». Pour mémoire, le modèle-classe-value est un modèle de design microformats qui résout désormais les problématiques d’accessibilité et de localisation.

J’ai inséré dans cette traduction un exemple de localisation d’une hCard avec domicile. La traduction reste ouverte à vos commentaires et corrections. Seul le lien original fait référence : URL raccourcie : http://ablognotlimited.com/s/106. Prochaine étape : implémentation sur ce site.

Non, vos yeux ne vous lâchent pas. Voici une autre contribution de ma série Parvenir Au Sémantique Avec Les Microformats (avec un remerciement spécial à Ben Ward pour son assistance technique) !

Cela fait environ six mois depuis la 7° partie, aussi vous pouvez vous demander pourquoi j’ai attendu si longtemps. Bon, disons que j’ai été occupée.

Mais même mon infâme calendrier ne pouvait m’empêcher de poster ce dernier billet, qui vient à la suite de l’annonce que le modèle-de-classe-value est officiel. Commençons la célébration !

Laissez-moi Rafraîchir votre Mémoire !

A moins que vous ne soyez une geek microformats comme moi, vous ne savez probablement pas ce qu’est le value-class-pattern ou le « modèle de classe value ».

Si vous avez suivi cette série et s’il vous est arrivé de lire mon article Microformats, hAccessibility & Moving Forward, vous en savez probablement plus que vous ne l’imaginez.

Mais ne me faites pas croire ça et vous restituer le contexte 411.

hAccessibilité

The Web Standards Project avait remarqué un problème d’accessibilité dans les microformats (défini "hAccessiblity") concernant le datetime design pattern.

Au coeur de ce problème, l’usage de abbr pour contenir une information de date lisible-par-les-humains, avec la valeur d’attribut title représentant la date lisible-par-les-machines ISO 8601. Cela ressemble à ça :

<abbr class="dtstart" title="2009-05-18">18 mai 2009</abbr>

Et quand c’est lui par un lecteur-écran, ce modèle de design fait que la date ISO 8601 se retrouve lue à l’utilisateur comme "deux zéro zéro neuf tiret zéro cinq tiret un huit." Ce qui est pire est quand la valeur ISO 8601 fait plus qu’une date, mais inclut aussi l’horaire comme dans cet exemple :

<abbr class="dtstart" title="2009-05-18T10:30:00">18 mai 2009 à 10h30</abbr>

Ceci donne une sortie dans le lecteur-écran : "deux zéro zéro neuf tiret zéro cinq tiret un huit T un zéro deux points trois zéro deux points zéro zéro."

La communauté pour l’accessibilité (à juste titre, IMO) soutenait que ce n’est pas accessible pour ces utilisateurs. Pendant ce temps, la communauté des microformats défendait que :

• les dates ISO 8601 sont en fait (sur toutes les cultures) lisibles par les humains;
• La valeur sémantique d’offrir des valeurs développées via abbr surpasse la problématique du lecteur d’écran
• Parce que la plupart des lecteurs d’écran n’ont pas développé de jeu.

Et ce débat pesait depuis des années.

Utilisabilité

Mais il n’y avait pas que l’hAccessibiliy qui était une déchirement du côté des microformats. C’étaient aussi les problèmes d’utilisabilité concernant le « modèle-de-design-date-horaire ».

Une fois de plus, le problème était la date ISO 8601 sous la valeur abbr title. Cette fois, le problème n’était pas lié à l’activité du lecteur d’écran, mais au comportement normal du navigateur. Vous voyez, la plupart des navigateurs affichent les valeurs abbr title sous forme de bulle d’aide pour l’utilisateur :

Seuls les plus geekies–des–geeks reconnaîtront probablement cette information. Pour tous les autres cela jette une (relativement petite) déchirure dans leur expérience de navigation. Et les parties lisible-par-les-machines des microformats sont supposées être invisibles pour l’utilisateur. Cet affichage de bulle d’aide n’est pas invisible et il peut être déroutant au quotidien pour les utilisateurs (non geeks).

Internationalisation

Une autre plainte souvent entendue sur les microformats est qu’ils ne sont pas "internationalisés." Ce qui veut dire, que quelques-unes des valeurs demandées par les microformats ne font sens que pour ces types qui publient en Anglais-Américain.

Imaginons que les valeurs type acceptées pour telephone dans la hCard : "cell" est la valeur requise à utiliser si vous indiquez un téléphone cellulaire. Les utilisateurs anglo-américains savent probablement ce qu’est un téléphone cellulaire, néanmoins, les lecteurs anglais et français appellent ces types de téléphones "mobile."

A nouveau, des questions d’utilisabilité.

Entrez dans le Modèle de Classe Value

Pour résoudre ces problématiques, la communauté des microformats a travaillé de façon diligente pendant un moment pour parvenir à la solution.
En fait, je me suis même essayé de publier et de tester à la main ce qui s’appelait initialement le « pattern-value-excerption ».

Et tout ce dur travail a finalement payé avec le modèle-de-classe-value, qui offre aux auteurs plusieurs options pour marquer leurs contenus sans avoir à se préoccuper des problématiques d’utilisabilité, d’accessibilité et de localisation mentionnées plus haut.

Information Date & Heure

Je viens de le dire, mais je le redirai : en utilisant le modèle-de-classe-value, les auteurs ont plusieurs options pour marquer l’information de date et d’horaire. Vous choisissez celle que vous aimez ; celle qui vous semble la plus pertinente pour votre contenu et vos préférences. J’en tremble rien qu’à y penser.

Tout d’abord, jetons un oeil à quelques-unes des options pour marquer l’information de date et d’horaire.

Vous Pouvez Encore Utiliser <abbr>

Le modèle de classe value n’abolit pas l’utilisation du modèle-de-design-abbr pour l’information date-horaire (AKA datetime design pattern). Si vous êtes du côté du "débat" qui pense qu’utiliser abbr avec les valeurs ISO 8601 de date et heure en title fait un sens sémantique, allez-y.

Avant que le modèle de classe value ne soit rentré dans la danse, voici comment vous pouviez marquer votre information date-heure pour dstart dans un hCalendar :

<abbr class="dtstart" title="2009-06-06T18:30:00">6 juin 2009 à 18h30</abbr>

Néanmoins, cette méthode est considérée comme dépréciée pour l’information date-heure. Les machines peuvent encore l’analyser, mais désormais avec le modèle-de-classe value, ce n’est plus la méthode recommandée.

Notez néanmoins que le modèle de design abbr en lui-même — pour les expansions de nom de pays, les coordonnées abrégées de latitude / longitude, etc. — est encore complètement valide. Ce n’est que pour l’information date-horaire que les choses changent légèrement.

Quels sont ces changements légers ?

<p class="dtstart"><abbr class="value" title="2009-06-06T18:30:00">6 juin 2009 à 18h30</abbr></p>

Remarquez que la sous-propriété dtstart est assignée au p contenant (qui peut être n’importe quel élément), alors que l’abbr est maintenant assignée au class="value". La valeur title ISO 8601 demeure la même.

Gardez à l’esprit cependant que cet exemple génère encore des problématiques d’accessibilité et d’utilisabilité derrière hAccessibility. Mais ce peut être la méthode préférée de quelques auteurs. La beauté du modèle de classe value est que vous pouvez choisir la méthode qui fonctionne le mieux pour vous.

Laissez Tomber le Modèle de Design Abbr

Si vous êtes soucieux des problématiques de lecteur d’écran et d’utilisabilité concernant le modèle de design abbr pour votre information de date-heure, le modèle de classe value est pour vous aussi, grâce au sous-ensemble value-title

Ainsi, au lieu d’utiliser abbr pour contenir le contenu lisible-par-les-humains avec la donnée machine dans l’attribut title, vous pouvez utiliser un élément span nommé class="value-title" et un attribut title contenant la date ISO 8601. Les machines reconnaissent alors que la valeur de la donnée pour cet élément (celle nommée class="value-title") devrait être extraite à partir du title, et non pas du texte à l’intérieur.

<p class="dtstart"><span class="value-title" title="2009-05-18T13:00:00">18 mai 2009 à 13h00</span></p>

Ceci réalise l’objectif des microformats pour des données humaines et machine, tout en ne provoquant pas l’affichage des infobulles dans le navigateur n’alertant pas les lecteurs d’écran de lire l’information machine sur la date. La plupart des navigateurs, néanmoins, afficheront encore la valeur en infobulle, l’exception étant Safari 3.0.3 sur Windows XP.

Séparer la Date & l’Heure

Pour démontrer plus en profondeur le niveau de flexibilité du modèle de classe value, vous pouvez aussi l’utiliser pour spécifier séparément la date et l’heure.

<p class="dtstart"><span class="value-title" title="2009-05-18">18 mai 2009</span> à <span class="value-title" title="13:00:00">1 heure de l'après-midi</span></p>.

A nouveau, dans cet exemple, j’ai laissé tombé l’usage du abbr et utilise l’approche span class="value-title". Mais cette fois, remarquez que j’ai spécifié séparément la date et l’horaire dans leurs propres éléments span class="value-title" (chacun avec l’information ISO 8601 appropriée dans le title). Les machines peuvent alors combiner les données séparées de date et d’heure à l’intérieur d’une valeur unique date-heure.

Et cette séparation de la date et de l’horaire peut être utilisée avec le modèle de design abbr. En fait, quelques types croient que cela aide à résoudre les problème d’utilisabilité avec les infobulles de date et d’heure. Spécifiquement, les infobulles individuelles résultantes pour la date et l’heure sont plus "utilisables" qu’une infobulle affichant la chaîne complète date-horaire :

Pour ces types, cette implémentation du modèle de classe value appliquée au modèle de design abbr est idéale :

<p class="dtstart"><abbr class="value" title="2009-06-06">6 juin 2009</abbr> à <abbr class="value" title="18:30:00">18h30pm</abbr></p>

Vous pouvez simplement définir séparément les valeurs de date et d’heure, chacune avec ses propres abbr class="value" et les valeurs title ISO 8601 appropriées.

Remarquez que je n’utilise pas le sous-ensemble value-title dans cet exemple. C’est parce qu’il ne devrait pas être utilisé avec le modèle de design abbr.

Au moment d’utiliser le modèle de classe value avec le modèle de design abbr, il est seulement nécessaire d’assigner class="value" à l’élément abbr. Les machines savent déjà comment extraire les date et heure ISO 8601 à partir de l’attribut abbr title, ainsi class="value-title" n’est pas nécessaire et invalide.

Sous-Ensemble Value-Title Avec <span>s Vides

Et il y a même encore une autre option à cette heure ; une qui élimine à la fois les infobulles et les expansions de lecteur d’écran.

Vous pouvez aussi utiliser l’approche class="value-title" avec un span vide … bon en fait pas vraiment vide. Un span contenant un seul espace blanc :

<p class="dtstart"><span class="value-title" title="2009-05-18T13:00:00"> </span>18 mai 2009 à 13h00</p>

Le résultat final est le même : les utilisateurs reçoivent une information compréhensible de date et d’horaire sur le navigateur et les machines reçoivent la date en ISO 8601. Et une fois de plus, pas de problèmes pour les lecteurs d’écran. Mais cette fois-ci, vous éliminez aussi les infobulles déroutantes.

Il y a quelques règles pour cette implémentation particulière, la première est d’utiliser cette approche "title-value vide" de façon restreinte. Ne l’utiliser que quand vous ne pouvez pas utiliser les autres modèles de design. Et quand vous l’utilisez :

• L’élément vide value-title devrait immédiatement suivre l’élément parent, apparaissant avant le contenu lisible-par-les-humains et sans imbrication supplémentaire.
• L’élément vide value-title ne devrait être utilisé qu’une fois seulement au moment de définir la valeur de la donnée pour une propriété unique. Aussi il ne devrait pas être utilisé au moment de séparer la date et l’heure dans – par exemple – la valeur dtstart de hCalendar.
• L’implémentation value-title vide ne devrait seulement (au moins à cette heure) s’appliquer qu’à :
  • Des valeurs de date ISO 8601, dateheure, timezone et durée
  • Des valeurs énumérées comme les sous propriétés de hCard tel, email adr
  • Les coordonnées pour les latitude et longitude dans le microformat geo
  • Les propriétés du numéro de téléphone

Pas Juste pour hCalendar

Les exemples que j’ai couverts à cette heure se concentrent sur l’information de date et d’heure qui apparaîtrait dans hCalendar. Mais vous pouvez appliquer le modèle de classe value à n’importe quel microformat qui références de l’information de date et d’heure. Par exmple, les anniversaires dans la hCard :

<p class="bday">Mon anniversaire est le <span class="value-title" title="1974-09-04">4 septembre</span>.</p>

Ou pour publier des dates dans hAtom :

<p class="published"><span class="value-title" title="2009-06-03">2 juin 2009</span></p>

Localiser Tout en Internationalisant

A ce stade, je n’ai fait que parler du modèle de classe value en relation avec les informations de date et d’heure. Mais vous souvenez-vous de ma précédente discussion sur les problématiques d’internationalisation ? Bon, jetons un oeil sur la manière dont le modèle de classe value peut aider.

Les types de Téléphone

Dans ma précédente référence, je mentionne spécifiquement les types de telephone dans la hCard. La seule valeur valide type pour spécifier un téléphone portable est "cell," mais tout le monde n’appelle pas ainsi ces types de téléphone.

Vous pouvez utiliser le modèle de classe value pour afficher la valeur locale que comprendront vos utilisateurs, et indiquer la valeur de microformat requise via span class="value-title" et l’attribut title :

<p class="tel"><span class="type"><span class="value-title" title="cell">mobile</span></span>: <span class="value">505-123-4567</span></p>

Dans cet exemple, du fait que j’utilise le sous-ensemble value-title, les machines sauront extraire la valeur de donnée type (cell) provenant de mon attribut title, plutôt que le texte à l’intérieur (mobile).

Numéros de Téléphone Localisés

Un autre exemple (que j’ai volé sur le Microformats Wiki, parce que je m’y connais pas assez en numéros internationaux) est pour les numéros de téléphone localisés. Dans ce cas, un numéro français :

<p class="tel"><span class="type">Home</span>: <span class="value">+33</span> (0) <span class="value">603 960 492</span></p>

La logique derrière cette implémentation est que la donnée valide pour le numéro de téléphone est +33603960492. Mais les français sont familiers avec l’inclusion du (0) pour une numérotation locale. A cette heure +330603960492 est un numéro invalide.

Aussi, pour donner aux utilisateurs français locaux l’information la plus utilisable et fournir à nouveau une donnée machine valide pour le numéro, vous appliquez le modèle de classe value. Dans cet exemple, le préfixe +33 est contenu par le span class="value" comme l’est le numéro 603 960 492. Néanmoins le (0) n’est pas contenu par quoi que ce soit. Ainsi les machines concatènent les deux textes à l’intérieur de span class="value" pour former la donnée valide et complète.

Et il existe encore bien plus d’usages du modèle de classe value. Mais ce billet de blog est déjà plus long que prévu (je ne sais pas pourquoi cela me surprend encore, compte tenu de ma passion pour la verbosité) et j’ai bien d’autres choses à faire … aussi je vous laisse explorer ça plus en profondeur.

Pick your Poison… (NDT : Vous avez l’embarras du choix)

Pas pour suggérer que les microformats sont du poison (en fait ils ne sont que plein de bonnes choses délicieuses), mais j’avais envie de balancer un titre de piètre qualité.

Le point demeure, vous choisissez quelle implémentation de modèle de classe value marchera pour vous. Vous n’êtes pas marié à une méthode de marquage de votre contenu avec ce modèle.

Comme pour mes propres préférences, je ne fais pas partie de ces types intéressés pour continuer à utiliser le modèle de design abbr pour les dates et les heures. Ne me faites pas dire ce que je n’ai pas dit. Je pense vraiment que abbr fait sens sémantiquement parlant pour contenir l’information de date et s’épancher avec ISO 8601 via le title.

Mais parce que j’aime tant la sémantique, je ne suis pas une vraie puriste. Je pense que la valeur non sémantique span class="value-title" offre pour l’accessibilité et l’utilisabilité bien plus de poids et l’emporte sur ma compulsion à être sémantique.

Néanmoins, je ne suis pas trop enthousiaste sur l’usage de l’approche value-title vide. Aussi je ne prévois pas de trop l’utiliser. Pour la majorité de mes propres implémentations utilisant les dates et les heures, je me vois bien faire contenir mon contenu avec span class="value-title" et de spécifier la donnée machine dans l’attribut title.

Il y aura probablement des exceptions à cela, mais c’est ce que j’aime dans le modèle de classe value. Il est flexible pour les besoins des auteurs de contenus.

Mettez à Jour Vos Implémentations

Même si j’ai trouvé le temps pour tomber cet article, je n’ai pas à cette heure encore trouvé le temps de mettre à jour mes implémentations de microformats existants. Mais je le veux … oh, oui je le veux. Et j’espère que vous le ferez, vous aussi.

A cette heure, les développeurs sont en train de travailler leurs outils pour reconnaître proprement le nouveau modèle de classe value. Optimus mène la danse avec sa mise à jour v0.8 qui supporte le modèle de classe value.

Aussi, assurez-vous de prendre votre part et de mettre à jour votre marquage.

Encore d’Autres à Venir ?

Aucune promesse sur ce point de futurs billets pour cette série. J’aimerais couvrir quelques autres microformats, mais avec mes obligations de livre, je doute fortement que j’aurai le temps … au moins pas jusqu’à ce mon manuscrit final soit bouclé en Août.

Mais si vous plongez pour en savoir plus, pourquoi ne pas revisiter quelques-uns de mes précédents articles couvrant :

• rel-home, rel-license, rel-me & rel-tag
• XFN
• hCard
• hCalendar
• hAtom
• hResume
• Thèmes & Problématiques

J’ai aussi donné récemment une rapide présentation des microformats qui pourrait vous intéresser (ou non).

Aussi, jusqu’à la prochaine fois … et oui, il y aura une prochaine étape en rapport avec les microformats même si elle ne fera pas partie de cette série.

En attendant la livraison de l’ouvrage d’Emily « Microformats Made Simple », j’ai pris plaisir à traduire ce billet critique d’Emily Lewis achevant sa série sur les microformats. Toutes vos critiques seront les bienvenues.

Selon ce que j’avais planifié quand je présentais cette série, nous parvenons à la fin de ce voyage excitant dans le monde des microformats.

Et après avoir passé tout ce temps à critiquer les implémentations spécifiques des microformats sur A Blog Not Limited, je ne voulais pas terminer la série sans quelque sorte de conclusion.

Mais plus j’y pensais, plus je réalisais que je n’étais pas prête pour conclure cette série. Il y a encore bien plus de microformats sur lesquels j’aimerais m’épancher et que je pourrai implémenter sur mon blog ou d’autres sites .

Aussi, ai-je décidé que cet article ne sera pas une conclusion, mais plutôt une réflexion de quelques thèmes et problèmes récurrents remarqués durant ma recherche sur les microformats.

Je ne m’enfoncerai pas plus avec ça.

Bon, non, non vraiment. En plaisantant, j’adore être un peu prétentieuse.

Récapitulatif de la Série

Avant de démarrer, jetons un œil sur ce dont nous avons déjà parlé :

• Indiquer les liens basés sur des relations avec l’attribut rel en 1° Partie
• Etendre l’attribut rel pour indiquer des relations sociales avec XFN dans la Partie 2
• Décrire les personnes, les lieux et organisations avec hCard dans la Partie 3
• Décrire des événements et des activités fondées-sur-les-dates-et-horaires avec hCalendar dans la Partie 4
• Décrire des blogs, des actualités et autres contenus pour la syndication avec hAtom dans la Partie 5
• Décrire les contenus des résumés et CV avec hResume dans la Partie 6

Maintenant que j’en ai terminé avec cette rétrospective, avançons sur les thèmes et questions que j’ai notés durant le processus d’écriture de cette série.

Thème : Sémantique

Dans chacun des articles de cette série, j’ai mentionné la sémantique comme étant l’une des raisons essentielles pour laquelle je suis une fan des microformats.

Ne me faites pas dire ce que je n’ai pas dit, j’adore les parseurs, les moteurs de recherche, les navigateurs et tout ce qui touche et utilise les microformats.

Mais pour moi, en tant que spécialiste du XHTML, la sémantique est vraiment bien plus importante. Et les microformats me permettent même d’être encore plus sémantique.

Le Web Sémantique

Mais je ne pense pas que tout le monde comprenne la sémantique telle qu’elle s’applique au web.

Il y a le Le Web Sémantique :

"… La plupart de l’information sur le Web est conçue pour une consommation humaine, et … la structure de la donnée n’est pas évidente pour un robot qui butine la toile. … l’approche du Web Sémantique développe à la place des langages pour exprimer de l’information sous une forme pouvant être traitée par la machine."

Tim Berners-Lee

En fait, le Web Sémantique est simplement une extension de notre web actuel, mais avec une meilleure information et plus de sens (sémantique) qui permettra aux ordinateurs/machines et aux humains de travailler ensemble plus efficacement.

Et même si les microformats ne sont pas une des spécifications formelles du Web Sémantique, ils supportent vraiment cet objectif de coopération machine-humain. En fait, l’un des fondements des microformats est "conçus tout d’abord pour les humains, puis pour les machines."

Marquage Sémantique

Puis, il y a la sémantique à laquelle je fais généralement référence quand je parle de sémantique : le marquage sémantique, qui est le marquage qui décrit ce qu’est quelquechose au lieu de ce à quoi cela ressemble.

C’est une approche pour le développement avec des standards du web : séparer l’information structurelle de l’information de présentation.

Et pour garder ce discours de geek prétentieuse, on lui a même donné un acronyme : POSH. (NDT ou le Bon Vieux HTML Sémantique aka CHIC).

Mais malgré le sobriquet, cette notion de séparer la structure de la présentation (mieux produite avec la validation) est l’un de mes concepts préférés dans le design/développement web.

Pourquoi mon préféré ? Bon, outre le fait d’être un standard (et, bon sang, j’en viens à adorer les règles quand elles viennent sur le web), le marquage sémantique décrit le contenu lui-même. Non pas ce à quoi ressemblera le contenu, mais ce qu’il est.

Une liste est un <ul>, un paragraphe est un <p>, un en-tête est un <h1>. Je suis une organisatrice/catégorisatrice naturelle, aussi cela fait sens pour moi. Je pense comme ça, aussi j’écris mon marquage de cette façon.

Mais, hormis cette fixation au stade anal, cela a aussi d’autres avantages, y compris celui associé au Web Sémantique : les ordinateurs se fichent bien de à quoi ressemble votre page web.

Les ordinateurs de soucient de la donnée et de l’information sur la page, et peuvent identifier certaines données comme en-têtes par exemple (ce qui offre un bonus pour booster organiquement le SEO).

Ainsi, eu égard à cette notion particulière de sémantique, les microformats portent la sémantique à un autre niveau en ajoutant des métadonnées et attributs au marquage pour fournir encore plus de valeur sémantique et de structure au contenu web.

CSS Sémantique

Encore mieux, le fait que les valeurs class sont ce qui définit un microformat (avec quelques exceptions en rapport aux attributs rel et title), les microformats supportent des conventions de nommage sémantique dans la CSS, dont je suis une farouche partisane.

De mon point de vue, si vous vous souciez d’utiliser un marquage sémantique, ne devriez-vous pas aussi étudier un nommage sémantique CSS ?

Par exemple, pourquoi déclarer un class="rightcolumn" quand il y aura une possibilité à l’avenir que la présentation puisse changer faisant que cet élément ne sera plus à droite ?

Au lieu de cela, déclarez un nom de classe qui décrit ce qu’est le contenu (comme class="relatedcontent") et utilisez les sélecteurs CSS pour définir sa présentation.

Les microformats font exactement cela. Les propriétés et sous-propriétés des microformats sont des valeurs de classe qui décrivent ce qu’est un élément. Par exemple, entry-title dans hAtom.

Problématique : Marquage Inutile

La discussion à propos du marquage sémantique est un va-et-vient incessant dans un problème qui amène beaucoup de gens à penser que c’est une raison de ne pas utiliser les microformats : marquage inutile.

En fait, ce "problème" particulier a été le coeur d’un article récent d’Andy Clarke : A tribute to Microformats (a reader question answered).

Le lecteur faisait remarquer à propos des microformats : "They really look like an excessive amount of tags and classes to me."

Et quand vous jetiez un oeil sur quelques exemples provenant du Microformats Wiki, le lecteur a raison :

1. <div class="vcard">
2.       <a class="fn org url" href="http://www.commerce.net/">CommerceNet</a>
3.       <div class="adr">
4.             <span class="type">Work</span>:
5.             <div class="street-address">169 University Avenue</div>
6.             <span class="locality">Palo Alto</span>, <abbr class="region" title="California">CA</abbr> <span class="postal-code">94301</span>
7.             <div class="country-name">USA</div>
8.       </div>
9.       <div class="tel">
10.             <span class="type">Work</span> +1-650-289-4040
11.       </div>
12.       <div class="tel">
13.             <span class="type">Fax</span> +1-650-289-4041
14.       </div>
15.       <div>Email:
16.             <span class="email">info@commerce.net</span>
17.       </div>
18. </div>

Ack! Divitis ! Spanitis !

Mais comme Andy l’explique en profondeur (et comme j’espère l’avoir démontré dans tous les exemples de cette série, "vous pouvez construire des [microformats] en utilisant des éléments de marquage qui sont appropriés au contexte du contenu que vous publiez."

Et en ce qui concerne le commentaire du lecteur sur le fait qu’il existe trop de classes, Andy fait remarquer :

"… in the case of mature and widely adopted Microformats such as hCard and hCalendar, each one of these attribute values comes not from the vivid imaginations of the inventors of Microformats, but have been reused from existing, related standards such as vCard and vCalendar. In fact, these attribute values are one–to–one correlations between the two formats and it is this that, for example, makes writing conversion scripts such as Brian Suda’s X2V possible."

Par conséquent, l’argument sur le fait le marquage excessif et la surcharge de classes l’emporte sur tout avantage des microformats n’est pas vraiment un argument. C’est une problématique d’ignorance qui est malheureusement propagée par de pauvres exemples de contenus microformatés.

Problématique : Accessibilité

Un autre sujet qui m’est souvent revenu à l’esprit durant cette série, c’est l’accessibilité et le fait que quelques parties de différents microformats ne sont pas accessibles aux lecteurs d’écran.

Modèle de Design Date-Heure

Mise à jour : 2 juin 2009

Le modèle-de-date-heure est désormais déprécié en faveur modèle de classe value. Voir la partie 8 de cette série pour en savoir plus sur ce nouveau pattern.

J’ai mentionné plusieurs fois le modèle-de-date-heure pour la relation avec hCard, hCalendar et hAtom, tout comme les problématiques d’accessibilité associées à ce modèle et le modèle-de-design-abbr.

Mais cela doit être discuté de nouveau du fait de ce problème d’accessibilité qui est l’une des raisons essentielles pour laquelle les types disent qu’ils n’utilisent pas les microformats.

Premièrement, qu’est-ce que le « datetime design pattern » ?

C’est l’approche recommandée pour définir l’information de date/horaire dans un microformat et cela utilise le modèle-de-design-abbr :

<abbr class="dtstart" title="2008-11-20T09:00:00">20</abbr>–<abbr class="dtend" title="2008-11-22T18:00:00">22 novembre</abbr>

Vous pouvez voir que l’élément conteneur est un <abbr>, où l’information contenue est "November 20" et la valeur de l’attribut title est "2008-11-20T09:00:00".

Ce pattern a été développé pour supporter l’un des principes basiques des microformats : conçus d’abord pour les humains, ensuite pour les machines. Tout en visant à fournir à la fois une information à la fois lisible par les humains et par les machines.

La logique est que les machines — telles que les applications web — utiliseront la valeur title, alors que les navigateurs afficheront pour les humains le contenu embarqué dans <abbr>.

hAccessibility

Aussi joli que ce modèle puisse paraître, il a ses problèmes.

Il y a un peu plus d’un an, The Web Standards Project a posté hAccessibility, qui détaille un problème significatif d’accessibilité avec le « datetime design pattern » utilisant le « abbr design pattern » : les lecteurs d’écrans lisent/parlent les valeurs title.

Par conséquent, à chaque fois que le « datetime design pattern » indique de placer l’information date/horaire ISO 8601 lisible par les machines dans le title, un lecteur d’écrans interprète littéralement la valeur à l’oral.

Imaginez que chaque fois que votre lecteur d’écran rencontre <abbr title="2008-11-20">, l’entendre dire ça : "Deux mille huit tiret onze tiret vingt." Et c’est même pire pour des valeurs plus longues avec l’information horaire.

Ceci n’est bien sûr pas convivial pour ces utilisateurs.

A cette heure, ces problématiques n’ont pas été résolues. La task force accessibilité du WaSP a proposé des alternatives au « abbr design pattern », y compris celle-ci qui fait sens selon moi :

<span class="dtstart" title="20070312T1700-06">March 12, 2007 at 5 PM, Central Standard Time</span>

Non, <span> peut ne pas être l’élément le plus sémantique à utiliser, mais la sémantique est un but, pas un absolu. Il y a des exceptions et la "pureté" de la sémantique n’est pas plus importante que la nécessité d’un contenu web accessible.

Avoir Raison vs. Faire Bien

A cette heure, cette problématique d’accessibilité n’a pas été résolue. Et plus j’en apprends à propos des microformats, moins je comprends pourquoi.

Il me semble, en tant qu’observateur extérieur, qu’il y a une plus grande concentration sur la posture et de savoir "qui a raison" sur cette question, plutôt qu’un effort sérieux pour faire que ça se résolve. Lisez juste quelques commentaires dans l’article du WaSP.

Je vous l’accorde, je comprends complètement les arguments sur le fait que <abbr> est le bon élément sémantique à utiliser parce que l’attribut <abbr> title offre une version augmentée des contenus que le tag contient (à l’opposé du contenu pour l’élément comme avec la plupart des tags).

Mais l’accessibilité sur le web (l’enfer, dans la vie) est d’une importance capitale. C’est un droit, pur et simple, que les personnes avec des handicaps aient un accès égal au contenu.

Ceci, outre le fait que cette question d’accessibilité est l’une des principales barrières pour les microformats, c’est pourquoi elle devrait être résolue sans délais (en fait, je pense que ce devrait déjà être résolu). Malheureusement, il ne semble pas que cela arrivera.

Et ceci ne fait que du mal aux microformats.

Thème : Pas Assez d’Outils = Pas Assez d’Avantages

Un autre thème découvert durant cette série (et qui est encore une autre raison pour laquelle les types n’implémentent pas les microformats) : Il y a un réel manque d’outils qui tirent partie des microformats.

Avant quand j’entendais cet argument, je ne le prenais pas suffisamment en considération. Parce que je connais un paquet d’outils qui utilisent, agrègent, extraient, cherchent, etc. les microformats :

Outils Navigateur

• Opera reconnaît le microformat rel-home quand il est utilisé dans le <link> d’un document <head>. Le navigateur a une Barre d’Outils de Navigation qui, une fois autorisée, permet aux utilisateurs de naviguer vers la page d’accueil.
• L’extension cmSiteNavigation Toolbar 0.8 pour Firefox (1.5-2.0) reconnaît rel-home et affiche les pages web en rapport avec la page en cours dans une barre d’outils pour aider à la navigation.
• L’extension Operator pour Firefox reconnaît plusieurs microformats (rel-tag, hCard, hCalendar) et fournit une recherche spécifique en contexte sur d’autres sites web comme Amazon, YouTube and Flickr.
• L’extension Tails Export 0.3.5 pour Firefox identifie les microformats sur une page web (hCard, hCalendar, hReview, xFolk, rel-license) et fournit des options d’export. Pour hCard et hCalendar, elle exporte respectivement le contenu microformat dans des fichiers .vcf et .ics, qui peuvent être ajoutés au carnets d’adresses et programmes d’agenda.
• rel-lint est un bookmarklet basé-sur-JavaScript qui vérifie s’il y a des valeurs XFN connues et fait remarquer celles qu’il ne reconnaît pas.
• L’extension Safari Microformats est utile pour les utilisateurs de Safari afin d’identifier les microformats hCard sur une page web et les sauvegarder dans leurs programmes de carnets d’adresses.
• Le Bookmarklet Microformats indépendant du navigateur imite la fonctionnalité de l’extension Safari pour l’information hCard.
• Michael Kaply a créé un script utilisateur hAtom pour l’extension Operator de Firefox. Ce script ajoute une fonctionnalité supplémentaire de bookmarking pour les occurences hentry.
• Mapanui est un bookmarklet en beta qui tire partie des microformats pour situer des adresses sur une carte, sans quitter la page.

Moteurs de Recherche & Spiders

• La plateforme ouverte SearchMonkey de Yahoo! tire parti du contenu RDF et microformat extrait pour les développeurs de parties-tiers.
• L’API Social Graph de Google indexe le web sur XFN pour aider à rendre le web plus social et qu’il y soit plus facile d’y trouver des amis.
• Creative Commons Search de Yahoo! filtre le contenu basé sur rel-license.
• Google offre aussi une recherche qui filtre les contenus selon rel-license : "Filtres de droits d’utilisation pour trouver du contenu ou des images réutilisables".
• Rubhub est un moteur de recherche social où vous pouvez proposer votre site, et il est indexé et comparé à d’autres sites dans l’index rubhub pour identifier toutes les relations sociales existantes.
• LeGraphe Social Ouvert de Plaxo fait tourner un crawler qui démarrer par une URL que vous saisissez et il cherche les liens rel="me" pour aider à la consolidation d’identité.
• XFN Graph crée des diagrammes sur la façon dont les sites sont liés les uns aux autres, en fournissant une représentation visuelle de relations sociales entre les auteurs de sites/blogs.
• Technorati Microformats Search cherche les hCards et d’autres microformats hCalendar et hReview.

Outils de Création

• Créateur XFN 1.1 est un wizard web qui crée des liens avec des valeurs XFN, et il est disponible en plusieurs langues.
• MT Blogroll 2.12 Manual est une extension Movable Type qui vous permet de définir les relations XFN pour les liens de blogroll.
• XFN Link Creator est un autre wizard qui crée des liens avec des valeurs XFN. Il vous permet aussi de spécifier le marquage contenu, tout comme les valeurs title pour les liens.
• WordPress Links Manager est configuré pour définir les relations XFN pour les liens de la blogroll.
• WP Microformatted Blogroll 0.2 est une extension WordPress qui produit des liens annotés de microformats sur votre blog.
• hCard creator est un formulaire simple qui génère une hCard à partir de l’information proposée.
• hCard microformat validator vous laisse proposer une URL avec du contenu hCard, et puis valide les propriétés et sous-propriétés.
• hCalendar Creator, un don de la communauté microformats, est un formulaire qui génère un marquage hCard et les propriétés/sous-propriétés à partir de l’inforamtion que vous proposez.
• Les extensions pnh_mf plugin et JMC_Event_Manager vous donnent un moyen facile d’ajouter du contenu microformat sur votre site/blog Textpattern.
• WordPress, a aussi quelques extensions qui aident les auteurs web à ajotuer des microformats sur leurs blogs/sites : Structured Blogging (aussi disponible pour MovableType) et WP-Microformats.
• Grâce à WaSP, il existe une extension microformats pour Dreamweaver, qui a été conçue pour DW 8, mais ils disent qu’elle fonctionne aussi pour MX et les versions supérieures.
• Le Conference Schedule Creator vous aide à créer un progamme complet de conférence avec tous les événements marqués avec hCalendar.
• Le thème WordPress Sandbox est un thème « squelette » qui peut être utilisé comme fondation pour personnaliser des thème WP et il supporte hAtom.
• Frances Berriman a créé une boucle PHP WordPress hAtom qui peut être ajoutée aux thèmes WP existants.
• hResume creator génère un hResume à partir de l’information proposée.
• Le « hResume Project » a créé une extension hResume pour WordPress.
• CV Antix est un constructeur de résumé/CV basé sur le web.

Parseurs & Extracteurs

• H2VX offre un Service de fils d’Evénements et Service de Fils de Contacts qui transforme l’information hCalendar et hCard en fichiers .ics et .vcf .
• Optimus est un transformateur robuste de microformats qui supporte tous les microformats et fournit un validateur.
• X2V de Brian Suda est une feuille de style XSLT qui extrait l’information hCalendar et hCard provenant d’une page web pour créer respectivement des fichiers iCalendar et vCard.
• Elias Torres a créé un script Greasemonkey hCalendar + Google Calendar Reminders qui identifie l’information hCalendar sur une page web et fournit une icône pour ajouter cet événement à votre Google Calendrier.
• Il existe un transformateur hAtom qui extrait hAtom provenant d’une page de façon à ce qu’il puisse être automatiquement transformé en XML pour un fil de syndication Atom.
• hAtom2Atom utilise XSLT pour transformer un marquage hAtom en Atom XML.
• Il existe un remote proxy utilisant hAtom2Atom produit par Luke Arno, tout comme un script de filtrage utilisant hAtom2Atom de Chris Casciano .
• hAtom transcoder est un autre transformateur qui non seulement génère Atom 1.0, mais aussi RSS 2.0.
• Il existe une extension hResume LinkedIn pour WordPress qui extrait le contenu du hResume provenant d’un profil public LinkedIn, qui peut ensuite être ajouté à une page WordPress..

Et ce ne sont là que quelques exemples trouvés durant ma recherche pour cette série. Il en existe bien plus encore.

What About Joe Six Pack?

Aussi, aucune question il y a des ressources.

Mais ensuite j’ai fait un petit sondage informel auprès de quelques collègues designers/développeurs web pour avoir leurs opinions sur les microformats.

Plusieurs types soulignaient que bien qu’il existe des outils pour aider les développeurs et geeks à produire facilement des microformats, il n’y a actuellement rien qui ne rende les microformats utiles pour les gens normaux.

Vu sous cet angle, je ne peux aider mais suis d’accord avec cet argument. C’est vrai, ma soeur n’a pas la moindre idée de ce que sont les microformats. Même si je lui ai montré une extension Firefox, elle ne les utilisera jamais ou ne s’en souciera même pas.

Ceci étant dit, j’utiliserai encore les microformats à chaque fois que j’aurai une opportunité de faire ainsi. Parce que je crois que ce manque de ce que qualifierai d’"innovation commune" est partiellement lié au fait que les microformats ne sont pas encore très utilisés.

Si tout le monde les utilisait dans leurs sites web, il y aurait alors bien plus de développement pour les supporter et démontrer leurs avantages à toutes les communautés (geek et non geek).

Et bien que je déteste le film, la citation "Si tu le construis, ils viendront" de Jusqu’aù bout du rêve me revient à l’esprit. Si plus de gens utilisaient les microformats, je pense que plus d’outils seraient développés.

En fait, je pense que la sortie récente de la boîte à outils Oomph Microformats est un pas dans cette direction.

J’ai récemment critiqué Oomph, et je trouve que c’est l’un des premiers outils microformats qui rend sur un site la présence des microformats apparente pour tout utilisateur, indépendamment de son navigateur et/ou des extensions.. Jetez simplement un coup d’oeil dans le coin en haut à gauche de ce site pour le voir en action.

Thème : RDF vs. Microformats

Bien que je n’ai pas une seule fois mentionné RDF dans tous les articles de cette série, ce serait négligent de ma part si je ne parlais pas de la division existante chez tous les supporteurs web sémantique : RDF est mieux que microformats et vice versa.

Mais après avoir fait un peu de recherche sur le sujet, je réalise que cette division est simplement le résultat de sensationalistes et de "know-betters" qui empestent notre industrie.

Ils ont besoin de quelque chose à défendre pour se sentir supérieurs, et le débat RDF vs microformats est une belle plate-forme pour se chamailler … tout particulièrement quand ces types ne se soucient pas de se comprendre les uns les autres.

RDF : Les Fondamentaux

Aussi, essayons de comprendre un peu RDF :

• RDF est une spécification du W3C pour décrire l’information, telle que titre, auteur, date de modification, contenu et information de copyright.
• RDF a été conçu pour fournir un commun afin de décrire cette information de manière à ce qu’elle puisse être lue et comprise par les applications informatiques, mais non affichée sur un navigateur pour les humains.
• RDF est écrit en XML de manière à ce que cette information puisse être échangée entre différents types d’ordinateurs utilisant différents types de systèmes d’exploitations et de langages d’application.

C’est la plus superficielle des descriptions, mais selon moi tout du moins, il apparaît que RDF et microformats ne partagent qu’une seule chose en commun : décrire l’information.

RDF est beaucoup plus concentré sur la vision du Web Sémantique.

Microformats, en Comparaison

Les microformats ne sont pas et n’ont jamais été conçus pour être un remplacement de RDF. Ils ont leur propre place et leur promesse : ajouter des métadonnées au contenu web avec des technologies existantes et des standards (XHTML et CSS).

Et ils sont simples pour encourager un usage et une consommation massive. RDF, en comparaison, tout du moins de mon point de vue, n’est pas simple du tout.

En outre, les microformats se soucient plus d’un marquage sémantique que le Web Sémantique. Bien que je crois vraiment que l’utilisation d’un marquage sémantique peut jouer un rôle dans le Web Sémantique en introduisant des métadonnées pour plus de personnes.

Par conséquent, même si vous verrez jaillir ces arguments RDF vs microformats, réalisez que ce sont des comparaisons illogiques entre des pommes et des oranges.

RDF et microformats sont deux choses différentes. RDF est un format de donnée pour Le Web Sémantique, alors que les microformats sont un modèle de design pour du balisage sémantique.

Tous les deux servent un objectif. Tous les deux sont valables.

Problématique : Information Compliquée

Durant toute ma recherche pour ces articles — sans mentionner le temps passé à implémenter les différents microformats — la seule chose qui m’a ennuyée était le manque d’information compréhensible, tout particulièrement sur le Wiki Microformats.

J’ai évoqué cette frustation dans la Partie 6, mais je le répète à nouveau parce que je suis d’humeur à tempêter.

Mais avant que je n’arrête à rouspéter sur ce point relativement mineur, j’ai vraiment besoin de reconnaître que le wiki est précieux. Ses auteurs et contributeur sont vraiment responsables de mon intérêt pour les microformats et de ma capacité à les implémenter.

Ceci étant dit, je trouve que la majorité du contenu sur le wiki est bien trop "techy" pour les microformats, et que les exemples (que j’ai cités) ne représentent pas les "bonnes pratiques" pour du marquage sémantique.

Les microformats sont volontairement simples. Mais quelque part, le contenu sur le wiki les fait apparaître comme quelque chose de bien plus compliqué que nécessaire.

Le wiki est aussi jonché d’information dépréciée et de liens brisés. Bon, édite-le alors, non ? C’est un wiki …

C’est vrai, je devrai prendre quelque responsabilité ici. Mais j’ai à peine le temps d’écrire ces articles pour mon propre blog.

Peut-être suis-je naïve de supposer que les types derrière le wiki aurait quelque sorte de modérateur ou de contrôle qualité, mais je ne peux m’empêcher de penser qu’ils ont une responsabilité pour s’assurer que l’information sur le wiki ne soit pas seulement mise à jour et correcte, mais représente le meilleur des microformats (tout particulièrement dans les exemples de code).

Je n’ai pas de solution à ce problème particulier autre que d’encourage plus de personnes à écrire leurs propres expériences des microformats, comme je l’ai fait. Je pense que les mettre en termes pratiques avec un langage conversationnel, rendra les microformats bien plus savoureux que ne le fait le wiki.

Aussi, le wiki a été mis à jour récemment, peut-être que l’attention sera renouvelée sur cette ressource particulière par les types des microformats.

Thème : I love Microformats

Le principal thème que j’ai remarqué durant cette série est que j’aime vraiment les microformats et prévois de les utiliser à chaque fois que j’en aurai l’opportunité parce qu’ils :

• Utilisent ce que je connais déjà (XHTML et CSS)
• Sont faciles à implémenter
• Ajoutent de l’information sémantique à mon contenu
• Ont du potentiel pour les technologies futures

Les arguments contre eux — manque de technologie et d’accessibilité — sont valides, mais pour moi, ce ne sont pas de vrais arguments.

Il y a des obstacles que les microformats doivent franchir, et pas de raison de ne pas passer un petit peu de temps supplémentaire et d’effort à les ajouter au balisage.

La Suite ?

Je vais faire une pause un moment sur ces articles qui ont été chronophages (pas trop longtemps, promis). Mais je sais que j’en écrirai quelques autres.

Il y a d’autres microformats qui m’intéressent vraiment, hReview, xFolk et XOXO. Aussi j’étudierai les opportunités d’essayer ces microforamts. Et ne manquerai pas d’écrire à leur propos.

Qu’est-ce que vais écrire ensuite ? J’ai plus de développement backend à faire sur ce blog, et prévois d’écrire à ce sujet. Je suis aussi intéressée à rendre ce blog (et tous les autres sites sur lesquels je travaille) prêts pour le WCAG 2.0, aussi je pense qu’une série se prépare sur l’accessibilité.

Hugs & Kisses

Pour conclure, je veux juste remercier tous ceux qui ont lu ces articles et participé à la discussion. Et merci à mes collègues qui m’ont offert leurs points de vue et feedbacks. Aussi merci à tous ceux qui m’ont contactée via email et Twitter pour me faire savoir combien ces articles leur ont été utiles.

Cette expérience a dépassé de loin toutes mes attentes. Non seulement j’en sais plus à propos des microformats que j’en j’ai démarré, mais me sens honorée d’avoir encouragé d’autres personnes à en savoir plus.

Mise à jour : 1/08/2009

Jan Sládek a traduit cet article en Tchèque Kódujme sémanticky s mikroformáty: náměty a problémy.

Passez le Mot

Vous voulez partager cet article avec d’autres ? Utilisez SVP l’URL raccourcie : http://tr.im/IbfJ.

Et bien sûr, vous pouvez toujours tweeter ça. Allez-y. Vous en avez envie.