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.

Ce qui suit s’inscrit dans la poursuite de travaux visant à mieux faire connaître les microformats. Vous trouverez ci-après une traduction en cours d’un article d’Emily Lewis publié le 15 octobre dernier sur son blog personnel. Seul le lien original fait référence. Vous pouvez m’aider à raffiner le contenu en ajoutant vos commentaires ou en éditant directement le code posé sur la page miroir de mon wiki-personnel. Ce billet s’inscrit dans la volonté « d’hAtomiser » ce thème WordPress fourni par Elegant Themes.

Parvenir au Sémantique avec les Microformats : 5° partie – hAtom

Durant le cheminement de cette série, j’ai discuté des différents microformats implémentés sur A Blog Not Limited : basés-sur-le-rel, XFN, hCard et hCalendar.

Maintenant, il est temps de parler du microformat hAtom, qui ajoute de la sémantique et de la structure au contenu web qui pourrait être syndiqué, comme les billets de blog ou les articles d’actualités.

L’Histoire : Atom

Le microformat hAtom est basé sur le format de syndication XML Atom.

A la différence de la représentation 1:1 de hCard et hCalendar vers vCard et vCalendar, le schéma hAtom n’est pas une réflexion exacte d’Atom.

Atom est un modèle robuste qui fournit bien plus de fonctionnalités que celles requises pour les contenus tels que des billets de blog. En tant que tel, hAtom utilise uniquement le minimum d’éléments requis ; c’est plus un sous-ensemble d’Atom.

Ceci dit, les propriétés et sous-propriétés hAtom sont basées sur les éléments correspondants dans la nomenclature hAtom.

Micro-contenu Pas Nécessairement de la Syndication

Même si hAtom est basé sur Atom, hAtom en lui-même n’est pas un format de syndication. L’auteur et éditeur de hAtom, David Janes explique :

… hAtom n’a jamais été conçu pour être un « format de syndication » ni pour concurrencer Atom ou RSS. Il est simplement conçu pour décrire le microcontenu sur les pages web, comme des billets de blog. Nous avons utilisé Atom parce qu’il fournit une nomenclature bien définie pour décrire de tels éléments.

Ainsi, hAtom n’est pas exclusivement pour le contenu web qui pourrait être syndiqué. Néanmoins, pour les besoins de cet article, je parlerai des billets de blog, qui sont généralement syndiqués.

L’Essentiel

Avant de rentrer dans les détails de hAtom, jetons un œil sur quelques règles fondamentales (similaires à celles pour hCard et hCalendar) :

• Les propriétés et sous-propriétés sont exprimées en valeurs class.
• Du fait de la relation avec Atom, les propriétés et sous-propriétés spécifiées hAtom reflètent les concepts des éléments hAtom.
• Les noms de propriété et sous-propriété sont sensibles à la casse.
• La propriété « racine » ne peut pas être combinée avec n’importe laquelle de ses propriétés/sous-propriétés. De ce fait <p class="hfeed author"> est invalide.

Et tout comme avec les autres microformats, le marquage utilisé n’est pas important (même s’il devrait être à la fois valide et sémantique.)

Les valeurs Class (propriétés/sous-propriétés) sont celles qui définissent le microformats hAtom.

Le Profil

Si vous choisissez d’implémenter hAtom, vous devriez aussi référencer son profil dans le <head> des pages web qui incluent le microformat :

<head profile="http://purl.org/uF/hAtom/0.1/">

Pour hCard et hCalendar, j’ai mentionné l’usage du profil combiné, qui couvre tous les microformats non-draft :

<head profile="http://purl.org/uF/2008/03/">

Néanmoins, hAtom est une spécification draft et son profil n’est pas couvert dans le profil combiné. Aussi, vous aurez besoin de spécifier explicitement son profil.

Si vous référencez aussi le profil combiné, vous ajoutez simplement le profil hAtom (Le W3C autorise plusieurs valeurs de profil, séparées par un espace blanc) :

<head profile="http://purl.org/uF/2008/03/ http://purl.org/uF/hAtom/0.1/">

Exemple : Billet Unique

Bon, assez parlé des origines. Voici comment j’implémente hAtom sur ma page de contenu avec l’article complet :

1. <div class="hentry">
2. <h3 class="entry-title">L'Accessiblité Web Est Importante</h3>
3. <abbr class="published" title="2008-08-28T13:14:37-07:00">28 août 2008</abbr>
4. <p class="category"><a href="http://www.ablognotlimited.com/articles/category/commentaries/" rel="tag">Commentaires</a></p>
5. <p><a href="#commentForm" title="Postez votre commentaire">Quelque chose à ajouter ?</a></p>
6. <div class="entry-content">
7. <p>The National Federation of the Blind v. Target lawsuit was settled this past Wednesday on the following key terms:</p>
8. …
9. </div>
10. <dl>
11. <dt>Tags:</dt>
12. <dd><a href="http://www.ablognotlimited.com/articles/tag/accessibility/" rel="tag">accessibility</a></dd>
13. <dd><a href="http://www.ablognotlimited.com/articles/tag/standards/" rel="tag">standards</a></dd>
14. <dd><a href="http://www.ablognotlimited.com/articles/tag/web+design/" rel="tag">web design</a></dd>
15. </dl>
16. </div>

Propriété Racine : hfeed

La racine de hAtom est hfeed, qui peut contenir une ou plusieurs entrées (dans cet exemple, les entrées sont des billets de blog).

Cette propriété racine est optionelle. Si elle n’est pas incluse, elle est supposée sur la page elle-même, ce qui est ce que j’ai fait (ou plutôt pas fait) dans l’exemple au-dessus.

Si c’est nécessaire, une page donnée peut avoir plusieurs hfeeds.

Propriété Requise : hentry

Chaque entrée doit être contenue avec la propriété hentry. Comme je le précisais, on peut appliquer là une ou plusieurs (illimité) propriétés hentry.

Pour cet exemple, il n’y a qu’un hentry parce que cette implémentation est sur une page avec le contenu complet d’un unique billet de blog. Je discuterai plus tard dans cet article de plusieurs entrées.

La propriété hentry contient toute l’information concernant l’entrée.

Sous-Propriété Requise : entry-title

L’une des sous-propriétés requises est entry-title, qui indique le titre de l’entrée.

Dans mon exemple, j’ai appliqué entry-title à un <h3> parce qu’en tant que titre, cela fait sens sémantiquement d’embarquer ça dans un titre.

Sous-Propriété Requise : author

Une autre sous-propriété requise est author, qui indique l’auteur de l’entrée.

Selon la spec., le contenu embarqué par la sous-propriété author doit aussi être marqué avec hCard appliqué à un élément <address>.

Attention : N’Affichez Pas le Nom de l’Auteur

Il existe néanmoins des cas, mon blog y compris, où les auteurs ne se soucient pas de lister le nom de l’auteur.

La spec. s’adapte à cette situation et lui permet d’être exclus du hentry si la page en elle-même contient l’information hCard dans un élément <address> assigné avec class="author".

Cette alternative est aussi expliquée dans les FAQ hAtom.

Du fait que j’ai cette configuration de hCard dans le pied de page de toutes mes pages, j’exclus author de mes implémentations hAtom et elles sont encore, techniquement, valides.

Pour les blogs avec plusieurs auteurs qui ne souhaitent pas afficher le nom de l’auteur, il n’existe pas actuellement d’alternative valide. Le contenu author doit être dans le hentry.

J’imaginerais bien qu’une solution CSS pour supprimer l’affichage visuel (display:none) dans ces cas pourrait être acceptable.

Attention : address Avec hCard

Cela amène une autre problématique : l’utilisation de <address> pour hCard.

Comme je le précisais dans la 3ème Partie, l’utilisation de <address> pour une hCard n’est valide que si la hCard est pour le propriétaire du document. La FAQ hCard déconseille d’utiliser <address> pour des hCards autres que le propriétaire du document.

Par conséquent, si les entrées hAtom sont rédigées par quelqu’un d’autre que le propriétaire du document, <address> ne serait pas l’élément sémantique approprié.

Cette problématique particulière est en train d’être discutée. Ce qui a été proposé est d’éliminer l’obligation d’utiliser <address>.

Sous-Propriété Requise : updated

La sous-propriété updated est aussi requise, et elle indique les date/horaire de mise à jour de l’entrée.

Il y a encore là une mise en garde pour updated : si cette sous-propriété n’est pas définie, la sous-propriété published est utilisée pour indiquer les date/horaire de mise à jour d’une entrée.

Dans mon exemple, vous remarquerez que je n’inclus pas une sous-propriété updated. Néanmoins j’inclus published.

Ce qui m’amène à …

Sous-propriété (optionnelle) : published

La sous-propriété optionnelle published est presque identique à updated dans le sens où elle renvoie les informations date/horaire pour l’entrée.

La différence principale étant que published est spécifique à quand l’entrée a été publiée pour la première fois, tandis qu’updated pourrait être la date de publication ou elle pourrait être des date/horaire ultérieurs quand l’entrée avait été mise à jour.

Il est aussi acceptable d’inclure à la fois published et updated pour décrire un élément unique contenant l’information de date/horaire :

<abbr class="published updated" title="2008-08-28T13:14:37-07:00">28 août 2008</abbr>

Dans mes implémentations, published seul est acceptable pour mes objectifs (et en plus sémantique), aussi c’est la sous-propriété que j’ai choisie de spécifier.

Datetime Design Pattern

Tant pour updated que published, l’information date/horaire pour hAtom est recommandé pour être exprimée en utilisant le datetime design pattern:

<abbr class="published" title="2008-08-28T13:14:37-07:00">28 août 2008</abbr>

Ce pattern spécifie que l’élément conteneur est un <abbr> ayant une valeur d’attribut title qui reflète l’information date/horaire « lisible-par-les-machines » alors que l’information contenue (et qui s’affiche dans les navigateurs) est de l’information date/horaire « lisible-par-les-humains ».

Pour aller plus loin, le pattern datetime spécifie que la valeur title devrait être exprimée en format ISO 8601.

Pour conclure, comme je l’ai traité précédemment, il y a des problématiques d’accessibilité concernant le « datetime design pattern ».

A cette heure, ces problématiques n’ont pas été résolues, même si la communauté des microformats travaille sur cet objectif.

Sous-Propriété Optionnelle : entry-summary

La sous-propriété entry-summary est optionnelle. Elle indique un résumé ou un extrait de l’entrée. Cette sous-propriété peut être utilisée un nombre illimité de fois dans hentry.

Sur mon blog je ne crée pas de résumé pour mes articles, aussi je n’inclus pas cette sous-propriété dans mes implémentations hAtom.

Sous-Propriété Optionnelle : entry-content

Une autre sous-propriété optionnelle est entry-content qui indique le contenu complet de l’entrée.

Dans mon exemple, tout mon contenu d’article est embarqué dans un <div class="entry-content"> unique. Néanmoins, la sous-propriété entry-content peut être utilisée un nombre illimité de fois dans un hentry.

Optionnelle : rel-bookmark

hAtom spécifie aussi une valeur d’attribut rel pour indiquer le permalien de l’entrée : bookmark.

Dans la 1^èrePartie de cette série, j’ai parlé des microformats-basés-sur-rel, qui sont utilisés pour indiquer la relation des liens (<a>) vers le document de destination (href).

rel-bookmark est simplement un autre exemple de description d’un lien, ce n’est pas un microformat en soi. Il n’existe seulement que comme une partie de hAtom pour décrire le permalien.

Si vous l’ignoriez, le permalien est l’URL de lien permanent pour un billet/article/entrée.

Avec hAtom, vous ajoutez simplement rel="bookmark" au permalien de l’entrée :

<a href="http://www.ablognotlimited.com/articles/web-accessibility-is-important/" rel="bookmark">L'Accessibilité Web Est Importante</a>

Vous pourrez remarquer que je n’ai pas de permalien dans mon premier exemple. Ceci parce que je suis généralement la règle du –of–thumb pour ne pas fournir un lien actif vers la page en cours (Nielsen’s #10 of the Ten Most Violated Homepage Design Guidelines).

Et parce que rel-bookmark est optionnel, mon hAtom demeure techniquement valide.

Si un hentry n’a pas de permalien indiqué, l’URL de la page est utilisée. Pour aller plus loin, si le hentry a un attribut id défini, cette valeur là est ajoutée à l’URL pour identifier les entrées individuelles.

Catégories en Combinant les Microformats

J’ai aussi mentionné le microformat rel-tag dans la 1^ère Partie.

Il est ajouté aux liens (<a>) qui indiquent ce qu’une page — ou une partie de cette page— traite. Basiquement, une organisation/categorisation avec le « tagage, » qui est très répandu dans les blogs.

hAtom tire partie de l’information rel-tag (la beauté de combiner les microformats) contenue à la fois dans hfeed et hentry :

• Les liens assignés rel="tag" qui apparaissent dans un hfeed (souvenez-vous, ce peut être exclus et supposé sur la page) mais en dehors du hentry sont considérés comme des « feed categories. »
• Les liens assignés rel="tag" qui sont contenus dans hentry sont considérés comme des « entry categories. »

Dans mon exemple, j’inclus des liens rel-tag dans mon hentry pour à la fois le lien « Category » et mes liens « Tags » :

<p class="category"><a href="http://www.ablognotlimited.com/articles/category/commentaires/" rel="tag">Commentaires</a></p>

<dd><a href="http://www.ablognotlimited.com/articles/tag/web+design/" rel="tag">web design</a></dd>

Remarquez que la spécification rel-tag exige que le lien destination (href) inclut la véritable valeur du « tag » comme segment final de la valeur d’URL. Ceci est connu comme « tagspace. »

Exemple : Plusieurs Billets

Maintenant que j’ai couvert les détails de hAtom, j’ai pensé que je pourrais aussi présenter un exemple sur la façon dont cela pourrait être implémenté pour aller plus loin qu’une entrée unique.

Sur mon blog, j’ai aussi ajouté hAtom sur ma page d’accueil pour présenter mes trois articles les plus récents :

1. <div class="hentry">
2. <h3 class="entry-title"><a href="http://www.ablognotlimited.com/articles/web-accessibility-is-important/" rel="bookmark">Web Accessibility Is Important</a></h3>
3. <abbr class="published" title="2008-08-28T13:14:37-07:00">Aug 28, 2008</abbr>
4. <p class="category"><a href="http://www.ablognotlimited.com/articles/category/commentaries/" rel="tag">Commentaries</a></p>
5. <div class="entry-content">
6. <p>The National Federation of the Blind v. Target lawsuit was settled this past Wednesday on the following key terms:</p>
7. …
8. </div>
9. <p><a href="http://www.ablognotlimited.com/articles/web-accessibility-is-important/" rel="bookmark">Continue Reading</a></p>
10. <dl>
11. <dt>Tags:</dt>
12. <dd><a href="http://www.ablognotlimited.com/articles/tag/accessibility/" rel="tag">accessibility</a></dd>
13. <dd><a href="http://www.ablognotlimited.com/articles/tag/standards/" rel="tag">standards</a></dd>
14. <dd><a href="http://www.ablognotlimited.com/articles/tag/web+design/" rel="tag">web design</a></dd>
15. </dl>
16. </div>
17. <div class="hentry">
18. <h3 class="entry-title"><a href="http://www.ablognotlimited.com/articles/plateau/" rel="bookmark">Plateau</a></h3>
19. <abbr class="published" title="2008-08-27T13:59:51-07:00">Aug 27, 2008</abbr>
20. <p class="category"><a href="http://www.ablognotlimited.com/articles/category/commentaries/" rel="tag">Commentaries</a></p>
21. <div class="entry-content">
22. <p>As I posted previously, I'm doing the one hundred push ups challenge: a six-week program designed to get me able to do 100 consecutive push ups. I am now on my seventh week.</p>
23. </div>
24. <p><a href="http://www.ablognotlimited.com/articles/plateau/" rel="bookmark">Continue Reading</a></p>
25. <dl>
26. <dt>Tags:</dt>
27. <dd><a href="http://www.ablognotlimited.com/articles/tag/exercise/" rel="tag">exercise</a></dd>
28. <dd><a href="http://www.ablognotlimited.com/articles/tag/fitness/" rel="tag">fitness</a></dd>
29. <dd><a href="http://www.ablognotlimited.com/articles/tag/push+ups/" rel="tag">push ups</a></dd>
30. </dl>
31. </div>
32. <div class="hentry">
33. <h3 class="entry-title"><a href="http://www.ablognotlimited.com/articles/getting-semantic-with-microformats-introduction/" rel="bookmark">Getting Semantic With Microformats, Introduction</a></h3>
34. <abbr class="published" title="2008-09-05T07:05:34-07:00">Sep 5, 2008</abbr>
35. <p class="category"><a href="http://www.ablognotlimited.com/articles/category/commentaries/" rel="tag">Commentaries</a></p>
36. <div class="entry-content">
37. <p>I'm an organizer with a sometimes frustrating need to pay attention to the smallest details.</p>
38. …
39. </div>
40. <p><a href="http://www.ablognotlimited.com/articles/getting-semantic-with-microformats-introduction/" rel="bookmark">Continue Reading</a></p>
41. <dl>
42. <dt>Tags:</dt>
43. <dd><a href="http://www.ablognotlimited.com/articles/tag/French+translation/" rel="tag">French translation</a></dd>
44. <dd><a href="http://www.ablognotlimited.com/articles/tag/hAtom/" rel="tag">hAtom</a></dd>
45. <dd><a href="http://www.ablognotlimited.com/articles/tag/hCalendar/" rel="tag">hCalendar</a></dd>
46. …
47. </dl>
48. </div>

Remarquez que dans cet exemple, j’utilise plusieurs instances de hentry ; une pour chaque article.

Remarquez aussi que j’indique les permaliens pour chacune des entrées (dans les liens pour le titre et « Continue Reading ») parce que ce ne sont pas des liens vers la page en cours.

A part ces deux différences, hAtom est implémenté de la même façon que dans mon premier exemple.

Implémentations Potentielles

Pour aller au delà des deux exemples présentés ici, il existe beaucoup d’autres possibilités d’implémenter :

• Une liste d’entrée qui apparaît sur une page d’archives
• Les Résultats de recherche pour les entrées
• Les « Bulletin board »
• Les commentaires

J’envisage d’implémenter hAtom sur mes propres archives et les pages des résultats de recherche (et peut-être même les commentaires, parce qu’ils ont besoin de hCard) dès que j’aurai un peu de temps libre pour modifier mon marquage.

Statut Projet

De tous les microformats que j’ai couvert dans cette série, hAtom fût le plus difficile. Je soupçonne personnellement que cela est dû au fait que c’est une spécification à l’état de projet (draft).

Basiquement, les défis que j’ai rencontrés sont minimes, mais légèrement frustrants :

• Il y a beaucoup moins d’information disponible sur la spécification hAtom et ses propriétés/sous-propriétés.
• Il existe plusieurs problématiques ouvertes en cours de discussion qui font que c’est ambitieux d’implémenter hAtom (par ex. l’utilisation de <address>).
• Bien moins de ressources/outils disponibles, comparé aux autres microformats.
• Les générateurs disponibles hAtom et parseurs ne (me) semblent pas être aussi à jour que la spec en elle-même. Ainsi, ils ne semblent pas prendre en considération les mises en garde que j’ai évoquées. (par exemple exclure author et rel-bookmark).

A cette heure, de mon point de vue, c’est tout ce qu’on attend d’une spécification projet. Elle est encore sujette à modification, travaux et discussions.

Je ne pense pas néanmoins, que cela dise que vous ne devriez pas implémenter hAtom, ou au minimum commencer à vous y familiariser. Au lieu de cela, essayez-là et soyez conscients que la spécification est en état de flux (relativement minimal).

Outils & Ressources

Bien qu’ayant mentionné le fait qu’il y a comparativement bien moins d’outils et ressources hAtom disponibles, il en existe quelques-uns là :

• Le Thème WordPress Sandbox est un thème « squelette » qui peut être utilisé comme base pour des thèmes WP personnalisés et il supporte hAtom.
• Frances Berriman a créé une boucle WP hAtom PHP qui peut être ajoutée aux thèmes WP existants.
• Michael Kaply a créé un script utilisateur hAtom pour l’extension Operator de Firefox. Ce script ajoute une fonctionnalité supplémentaire de mise en signets pour les occurences hentry. (Coup de chapeau à mon ami Chris Harrison pour m’avoir signalé ce script.)
• Il existe un transformateur hAtom qui extrait hAtom d’une page web de manière à ce qu’il puisse être automatiquement transformé dans le XML pour un fil de syndication Atom.
• hAtom2Atom utilise XSLT pour transformer un marquage hAtom en XML Atom.
• Il existe un proxy distant utilisant hAtom2Atom construit par Luke Arno, tout comme un script filtre utilisant hAtom2Atom produit par Chris Casciano.
• Optimus est un transformateur robuste de microformats qui supporte hAtom. En outre, il offre un validateur qui supporte hAtom.
• Le transcodeur hAtom est un autre transformateur qui non seulement produit du Atom 1.0, mais aussi du RSS 2.0.

Dans la Jungle

Même si hAtom est une spécification projet (draft), il est en train d’être adopté :

• Google a ajouté la fonctionnalité pour les liens permanents hAtom à son Bloc-Notes.
• Le nouveau système de gabarits de mise en page de Blogger supporte hAtom.
• Spinn3r a ajouté la fonctionnalité hAtom entry-content à son service 2.1 d’indexation de blogs.

Et il existe encore plus d’exemples hAtom dans la jungle.

Avantages

Syndication (X)HTML

Je pense que l’un des avantages les plus cools d’hAtom est son portentiel pour la syndication XHTML.

Dans la liste des outils et ressources, je mentionne deux transformateurs. Ceux-ci utilisent XSLT pour transformer le XHTML avec hAtom en XML pour un fil Atom ou RSS.

Ceci veut dire que vous n’avez pas besoin de créer ou maintenir des fichiers séparés Atom ou RSS XML pour la syndication. En utilisant simplement hAtom et l’un de ces transformateurs, la syndication XML est automatiquement générée.

Essayez vous-même. Tout ce que avez à faire est de faire précéder l’URL d’une page qui contient hAtom (par ex. http://www.ablognotlimited.com/) avec l’URL de l’un des transformateurs (http://transformr.co.uk/hatom/) :

<a href="http://transformr.co.uk/hatom/http://www.ablognotlimited.com/">Fil Atom pour A Blog Not Limited</a>

Le lien résultant crée le XML Atom et les utilisateurs le sélectionnent pour s’abonner :

Personnellement je n’ai pas encore implémenté cette option sur mon site, parce que j’ai des fils RSS personnalisés pour lesquels je ne me soucie pas de perdre la personnalisation. Tout ceci pour ne pas dire, que j’ai encore à ajouter les fils Atom.

Néanmoins, ces transformations sont désormais sur ma liste de fonctionnalités à explorer pour ce blog.

Sémantique

Vous n’alliez tout de même pas penser que j’allais oublier ça, non ? Bien sûr que non.

En tirant partie des standards existants (les éléments et attributs XHTML), les microformats ajoutent de la valeur sémantique au contenu web. Et la sémantique aide à la fois les humains et les processus machines, à chercher et comprendre le web.

Les microformats encouragent aussi les standards du web … les approches d’un standard pour baliser le contenu, y appliquer de l’information de classe et de processus de développement.

La sémantique est bonne. Les standards sont bons. Les microformats sont bien.

A Venir dans la 6^ème Partie

Ceci conclut ma « couverture » du microformat en projet hAtom.

Dans Parvenir à la Sémantique, 6^ème Partie, je discuterai du microformat hResume pour l’information dans les résumés et CV.

Restez branchés !

Nous voici de nouveau à plonger dans le monde excitant (au moins pour moi) des microformats. Basé sur ce que j’avais planifié au début, cet article marque le mi-parcours de la série. A ce stade, j’ai discuté de trois implémentations des microformats sur A Blog Not Limited :

• Spécifier les relations fondées sur les liens en utilisant l’attribut rel dans la 1^ère Partie
• Donner aux liens un « visage humain » en utilisant le microformat XFN dans la 2^ème Partie
• Décrire les personnes, les sociétés et lieux avec le microformat hCard dans la 3^ème Partie

Pas mal. Mais cela ne fait que gratter la surface des microformats.

Aussi, allons droit vers le microformat hCalendar, que j’utilise pour ajouter de la sémantique et de la structure à mon contenu pour les événements et activités basés sur des dates et heures.

Origines : iCalendar

iCalendar (ou iCal) est un standard pour partager des données de calendrier. Plus fréquemment, il est utilisé dans les échanges d’email, bien qu’il ne soit pas seulement limité à ce médium.

Comme la hCard, hCalendar a été introduit de manière à ce que les auteurs web puissent inclure des données iCalendar dans leurs pages web.

hCalendar est une représentation 1:1 du iCalendar, qui permet aux parseurs d’extraire de l’information d’événement provenant d’une page web de manière à ce qu’elle puisse être utilisée dans les programmes de calendriers (parmi d’autres usages).

Note historique : iCalendar est basé sur vCalendar (Virtual Calendar), qui est une application de calendrier en open source pour publier et maintenir des événements et rendez-vous en ligne. vCalendar a été développé avec le format de carte de visite électronique vCard.

Activités Fondées sur Date/Heure

Le microformat hCalendar décrit le type d’information à propos d’évènements (ou tout ce qui est basé sur les date/heure) que vous auriez sur un calendrier, à savoir (mais non limité) :

• Résumé
• Date et heure
• Lieu
• Description détaillée
• Récurrence

Les Bases

Tout comme hCard, hCalendar a quelques règles de base :

• Les propriétés et sous-propriétés sont exprimées sous des valeurs class.
• Du fait de la relation 1:1 avec iCalendar, les propriétés spécifiées hCalendar sont basées sur les noms de propriétés de iCalendar (à savoir, vevent).
• Les propriétés et sous-propriétés sont sensibles à la casse.
• La propriété « racine » ne peut pas être mélangée avec n’importe laquelle de ses propriétés. De ce fait, <p class="vevent summary"> est invalide.

Et même si ce n’est pas une règle, il est important de garder ça à l’esprit : le marquage utilisé importe peu.

Les valeurs de classe (propriétés/sous-propriétés) définissent le microformat hCalendar.

Ceci étant dit, j’encourage vraiment le marquage sémantique (et cela va sans dire valide).

Le Profil

Comme pour tous les microformats, il est recommandé de faire référence au profil hCalendar dans le <head> des pages web qui contiennent le microformat :

<head profile="http://purl.org/uF/hCalendar/1.0/">

Le W3C autorise plusieurs valeurs de profils, séparées par des espaces blancs, ainsi vous pouvez lister plusieurs profils si vous choisissez :

<head profile="http://gmpg.org/xfn/11 http://purl.org/uF/hCard/1.0/" http://purl.org/uF/hCalendar/1.0/">

Cependant, si vous référencez des microformats-non-draft (et hCalendar est non-draft), vous pouvez utiliser à la place l’URL profil combinée, qui couvre tous les microformats non-draft :

<head profile="http://purl.org/uF/2008/03/">

Si vous faites référence à la fois à des microformats non-draft et draft, vous pouvez utiliser ce profil combiné avec les profils pour les nouveaux/draft microformats.

L’exemple

Ce blog est encore relativement nouveau. Aussi, je n’ai pas eu beaucoup d’opportunités de lister de l’information d’évènement.

En fait, je n’ai qu’un exemple vivant, grâce à un article sur un BarCamp récent à Albuquerque où j’ai utilisé le microformat hCalendar :

1. <div class="vevent">
2. <p>
Oui, c'est un billet court, mais marquez ça dans vos agendas :
<a href="http://barcamp.org/BarCampAlbuquerque"
class="url summary">
<span class="category">BarCamp</span>
Albuquerque 3</a>
aura lieu ce week-end.
</p>
3. <dl>
4. <dt>Quand :</dt>
5. <dd><abbr class="dtstart"
title="2008-09-13T09:00:00">13</abbr>–
<abbr class="dtend" title="2008-09-14T18:00:00">14 septembre</abbr>,
à partir de 9h00 jusqu'à 18h00 les deux jours.</dd>

6. <dt>Où :</dt>
7. <dd class="location vcard">
<a class="fn org url" href="http://www.chefwhite.com/cjw_cafe.php">CJW Cafe</a>
à <a href="http://maps.google.com/maps" class="adr">
<span class="street-address">4801 Alameda
<abbr title="Boulevard">Blvd</abbr>
<abbr title="Northeast">NE</abbr>
</span>,
<span class="locality">Albuquerque</span>,
<abbr class="region" title="New Mexico">NM
</abbr> <span class="postal-code">87113
</span>
</a>
</dd>

8. <dt>Quoi :</dt>
9. <dd class="description">
Un évènement de
<abbr class="duration" title="P2D">deux jours</abbr> pour tout ce qui concerne le web — design (visuel, expérience, architecture de l'information), technologie (infrastructure, programmation), social et nouveaux médias, et d'autres trucs simplement vraiment cools.</dd>
10. </dl>
11. </div>

Les Parties de la Somme

Décomposons cet exemple avec ses parties.

La Racine : vevent

Vous remarquerez que la propriété racine dans mon exemple est vevent, plutôt que vcalendar. Ceci parce hCalendar a un élément racine optionne du vcalendar, qui n’est obligatoire que si vous décrivez plus d’un calendrier d’événements sur une page donnée.

Pour une page avec un unique calendrier d’événements, la propriété vcalendar est présumée sur la page elle-même.

Le fait que mon exemple soit un événement unique dans un « calendrier, » unique, je place toute mon information d’événement dans <div class="vevent">. Ceci indique que tout le contenu embarqué à l’intérieur décrit un événement unique.

Une fois de plus, l’élément conteneur pourrait être n’importe quoi (<dl>, <ul>, <p>, <span>, etc.) la <div> est simplement appropriée pour mon exemple.

Propriétés Requises : summary & dtstart

Les seules propriétés requises pour hCalendar (autres que la racine vevent) sont summary et dtstart.

summary

La propriété summary décrit un synopsis bref de l’événement. Le contenu embarqué par cette propriété est typiquement ce qui s’affiche dans un programme de calendrier sous le nom ou titre de l’événement.

Ainsi dans mon exemple, « BarCamp Albuquerque 3″ est contenu par summary, aussi c’est l’information qui s’affiche comme le nom/titre dans mon calendrier personnel :

<p>Oui, c'est un billet rapide, mais à marquer dans vos agendas : <a href="http://barcamp.org/BarCampAlbuquerque" class="url summary"><span class="category">BarCamp</span> Albuquerque 3</a> c'est ce week-end.</p>

dtstart

La propriété dtstart décrit les date/horaire pour le démarrage de l’événement. Dans mon exemple, « 13″:

<dd>
<abbr class="dtstart"
title="2008-09-13T09:00:00">13
</abbr>–<abbr class="dtend"
title="2008-09-14T18:00:00">14 septembre</abbr>,
de 9h00 à 18h00 les deux jours</dd>


Date/Time Design Pattern

Remarquez que l’élément contenant pour dtstart est un <abbr>, là où l’information contenue est est « 13″ et la valeur d’attribut title est « 2008-09-13T09:00:00″:

<dd><abbr class="dtstart"
title="2008-09-13T09:00:00">13</abbr>
–<abbr class="dtend" title="2008-09-14T18:00:00">14 septembre</abbr>,
de 9h00 à 18h00 les deux jours</dd>


C’est l’approche actuellement recommandée pour définir l’information date/horaire dans un microformat — connue sous le datetime design pattern (qui est une extension du abbr design pattern).

Ce pattern a été développé pour supporter l’un des principes fondamentaux des microformats : designer d’abord pour les humains, ensuite pour les machines. Visant pendant tout ce temps, à fournir une information qui soit à la fois lisible par les humains et par les machines.

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

Aussi, en tant que partie de la spécification pour utiliser ce « datetime pattern », l’information date/horaire devrait être spécifiée dans un ISO 8601 :

• AAAA-MM-JJThh:mm:ss — « A » représente les nombres entiers de l’année, « M » représente les nombres entiers du mois, « J » représente les nombres entiers du jour, « h » représente les nombres entiers des heures, « m » représente les nombres entiers des minutes et « s » représente les nombres entiers des secondes.
• AAAA-MM-JJThh:mm:ssZ — « Z » est utilisé pour indiquer le GMT.
• AAAA-MM-JJThh:mm:ss+hh (ou -hh) — les « +hh » et « -hh » indiquent le décalage horaire en heure GMT.

Pour dire ça dans des termes un peu plus compréhensibles, 2008-09-30T13:00:00 = 30 septembre 2008, 13h00 (heure locale).

Le caractère « T » dans ces exemples sépare l’information de date de l’information d’horaire.

Si vous n’avez qu’une date, omettez simplement le « T » et l’information horaire le suivant. De même, si vous n’avez qu’un horaire, omettez le « T » et l’information de date le précédant.

Il existe néanmoins et hélas, quelques problèmes d’accessibilité avec ce pattern, problèmes que je décrirai plus tard dans cet article. A cette heure, continuons avec mon exemple.

Le Reste des Propriétés Date/Horaire

Il existe deux autres propriétés date/horaire (et optionnelles) que j’ai ajoutées : dtend et duration.

dtend

La propriété dtend décrit les date/horaire de la fin de l’événement. Dans mon exemple, « 14 septembre »:

<dd>
<abbr class="dtstart" title="2008-09-13T09:00:00">13</abbr>
–<abbr class="dtend"
title="2008-09-14T18:00:00">14 septembre</abbr>,
de 9h00 à 18h00 les deux jours</dd>

duration

La propriété duration décrit la durée (en temps) de l’événement.
Dans mon exemple, deux jours :

<dd class="description">Un évènement de <abbr class="duration" title="P2D">deux jours</abbr> pour tout ce qui concerne
le web — design (visuel, expérience, architecture de l'information), technologie (infrastructure, programmation), social et nouveaux médias, et d'autres trucs simplement vraiment cools.</dd>

Tout comme pour l’information de date/horaire, l’information de durée est spécifiée en utilisant le « datetime design pattern », où l’information « lisible-par-les-machines » est indiquée par la valeur title et l’ »information-lisible-par les-humains » est contenue par le <abbr>.

Aussi, la valeur de « duration » title est spécifiée selon ISO 8601, qui indique que la valeur est précédée par un « P » pour indiquer une période de temps.

Cette période de temps peut être exprimée en années (Y), mois (M), semaines (W), jours (D), heures (H), minutes (M) et/ou secondss (S).

Voici quelques exemples pour clarifier cela :

• P2Y = durée de 2 ans
• P10D = durée de 10 jours
• P3H = durée de 3 heures
• P2W = durée de 2 semaines weeks
• P12DT8H30M = durée de 12 jours, 8 heures et 30 minutes

Parlons Accessibilité

J’ai rapidement évoqué dans la 3ème Partie qu’il y avait eu récemment quelques discussions sur les problèmes d’accessibilité avec le datetime design pattern.

Le point crucial du problème d’accessibilité est la façon dont les lecteurs d’écran interprètent les valeurs d’attribut title : ils les lisent/parlent.

Aussi, là où le datetime design pattern indique de mettre l’information ISO 8601 de date/horaire lisible par les machines dans le title, un lecteur d’écran déclame littéralement la valeur.

Imaginez entrendre ça à chaque fois que votre lecteur d’écran rencontre <abbr title="2008-09-30"> : « Deux mille huit tiret zéro neuf tiret trente. » Et c’est même encore pire pour les valeurs plus longues avec l’information sur l’horaire.

On peut soutenir que ceci n’est pas « human-friendly » pour ces utilisateurs.

A cette heure, ces problèmes n’ont pas été résolus. Il y a eu queques alternatives proposées, mais la communauté des microformats continue à discuter de la meilleure approche pour avancer afin de résoudre ces problèmes d’accessibilité et de rester cohérente avec l’esprit des microformats.

Pour moi et mon blog personnel, mes référents indiquent que je n’ai pas de visiteurs avec des lecteurs d’écran. Aussi, je ne suis pas préoccupée par l’implémentation du « datetime design pattern » sur ce blog.

Néanmoins, travaillant pour une grande entreprise, le manque d’accessibilité n’est tout simplement pas acceptable (pour moi et mon superviseur direct, même si je suis certaine que les « gros bonnets » pourraient moins s’en soucier).

Je suis désireuse de voir comment vont ces problèmes vont être résolus, de manière à ce que je puisse implémenter correctement l’information date/horaire en microformats et que cela puisse être encore supporté par tous les utilisateurs de lecteurs d’écrans.

Désormais, il est temps de revenir à l’exemple et des propriétés restantes utilisées …

Le Reste du Reste

Mon exemple comprend quatre propriétés supplémentaires (aussi optionnelles) : url, category, location and description.

url

La propriété url décrit un lien (<a>) pour l’événement :

<p>Oui c'est un billet rapide, mais marquez vos agendas : <a href="http://barcamp.org/BarCampAlbuquerque" class="url summary"><span class="category">BarCamp</span> Albuquerque 3</a> c'est ce week-end.</p>

Vous remarquerez que j’ai ajouté la propriété url à la propriété summary. Ceci tout simplement parce que le contenu embarqué par le <a> était simplement la valeur pour mon summary. D’autres implémentations pourraient être différentes.

category

La propriété category décrit le type d’événement. Dans mon exemple, « BarCamp » :


<p>Oui c'est un billet rapide, mais marquez vos agendas :
<a href="http://barcamp.org/BarCampAlbuquerque" class="url summary">
<span class="category">BarCamp</span> Albuquerque 3</a>
c'est ce week-end.</p>

A la différence des propriétés évoquées plus haut, category peut utiliser un nombre illimité de fois. Quelques exemples communs de valeurs de category sont :

• Rencontre
• Expo
• Vacances
• Anniversaire
• Conférence

Dans un certain sens, category est un moyen de « taguer » l’événement. Aussi, si j’avais choisi de marquer mon exemple pour y inclure un lien vers le site principal du BarCamp, j’aurais aussi utilisé microformat rel-tag pour accompagner category :

<p>Vous pourriez vous demander ce qu'est un
<a href="http://barcamp.org/"
class="category" rel="tag">BarCamp</a> ?
</p>

Souvenez-vous, rel-tag ne peut être uniquement utilisé que sur des liens (<a>).

location

La propriété location décrit où aura lieu l’événement.


<dd class="location vcard"><a class="fn org url"
href="http://www.chefwhite.com/cjw_cafe.php">CJW Cafe
</a> au <a href="http://maps.google.com/maps" class="adr">
<span class="street-address">4801 Alameda
<abbr title="Boulevard">Bd</abbr>
<abbr title="Northeast">NE</abbr>
</span>,
<span class="locality">Albuquerque</span>,
<abbr class="region" title="New Mexico">NM</abbr>
<span class="postal-code">87113</span></a>
</dd>

Dans mon exemple, je fournis le nom du lieu et son adressse. Néanmoins, ce peut être tout simplement le lieu, ou juste l’adresse ; les deux ne sont pas requis.

description

Pour finir, la propriété description décrit un synopsis plus détaillé de l’évènement que summary :


<dd class="description">Un évènement de
<abbr class="duration" title="P2D">deux jours</abbr>
pour tout ce qui concerne le web — design (visuel, expérience, architecture de l'information), technologie (infrastructure, programmation), social et nouveaux médias, et d'autres trucs simplement vraiment cools.
</dd>

Ce Que Je N’ai Pas Ajouté

Il existe plusieurs autres propriétés souvent utilisées pour hCalendar que j’ai choisies simplement de ne pas ajouter à mon exemple :

• dtstamp indique les date/horaire à laquelle l’information hCalendar a été créée.
• last-modified indique les date/horaire à laquelle l’information hCalendar a été mise à jour.
• status indique la confirmation d’événement. Les valeurs autorisées sont « cancelled, » « confirmed » et « tentative. »
• class indique la classification d’événement. Les valeurs autorisées sont « private, » « public  » et « confidential. »
• rrule indique la récurrence régulière d’un événement. Si cette propriété est utilisée, elle a une sous-propriété obligatoire de freq pour indiquer la fréquence de la récurrence, qui est spécifiée plus en profondeur par des qualifiants (à savoir, count, interval).
• rdate indique des événements qui arrivent irrégulièrement. La valeur title renvoie les dates irrégulières (séparées par des virgules).

Et il en existe encore d’autres qui peuvent être utilisées. Regardez les exemples hCalendar sur le wiki pour plus de détails.

hCalendar + hCard

Peut-être que vous avez remarqué que mon marquage hCalendar comprenait des propriétés et sous-propriétés hCard :


<dd class="location vcard">
<a class="fn org url"
href="http://www.chefwhite.com/cjw_cafe.php">CJW Cafe</a> au
<a href="http://maps.google.com/maps" class="adr">
<span class="street-address">4801 Alameda
<abbr title="Boulevard">Blvd</abbr>
<abbr title="Northeast">NE</abbr></span>,
<span class="locality">Albuquerque</span>,
<abbr class="region" title="New Mexico">NM</abbr>
<span class="postal-code">87113</span></a>
</dd>

Comme je l’évoquais dans la 3^ème Partie, combiner les microformats est facile, et là où cela produire du contenu contextuel, cela ajoute plus de valeur sémantique au contenu (et vous savez ce que j’en pense).

Pour aller plus loin, cela donne à l’utilisateur juste quelques autres types de données qui peuvent être extraites et utilisées, comme une vCard pour son carnet d’adresses.

Dans cet exemple, la propriété location du hCalendar fait sens pour être aussi marquée avec vcard. Même si je n’ai fait que rajouter la ville, j’aurais pu encore ajouter les propriétés/sous-propriétés de hCard.

Langage Naturel

J’ai parlé aussi d’utiliser les microformats en langage naturel (dans le flux de phrases normales) dans la 3ème Partie, et hCalendar ne fait pas exception à ce concept.

Vous remarquerez que dans cet exemple, quelques informations du hCalendar sont directement dans le flux de mon contenu.

J’aurais pu mettre toute l’information du hCalendar dans des phrases naturelles plutôt que de « découper » quelques-uns des détails dans des <dl> :

1. <div class="vevent">

2. 
<p>Oui, c'est un billet rapide, mais à marquer dans vos calendries :
<a href="http://barcamp.org/BarCampAlbuquerque"
class="url summary">
<span class="category">BarCamp</span> Albuquerque 3</a> c'est ce week-end,
<abbr class="dtstart" title="2008-09-13T09:00:00">13
</abbr>–
<abbr class="dtend"
title="2008-09-14T18:00:00">14 septembre</abbr>, de 9h00 à 18h00
<abbr class="duration" title="P2D">les deux jours</abbr>.
</p>
3. <p class="description">Ce BarCamp de l'année traitera de tout ce qui concerne le web : design (visuel, expérience, architecture de l'information), technologies (infrastructure, programmation), social et nouveaux medias, et d'autres trucs qui sont tout simplement vraiment cools.</p>
4. 
<p class="location vcard">
<a class="fn org url" href="http://www.chefwhite.com/cjw_cafe.php">CJW Cafe</a>
(sur <a href="http://maps.google.com/maps" class="adr">
<span class="street-address">4801 Alameda
<abbr title="Boulevard">Blvd</abbr>
<abbr title="Northeast">NE</abbr>
</span>, <span class="locality">Albuquerque</span>,
<abbr class="region" title="New Mexico">NM</abbr>
<span class="postal-code">87113
</span>
</a>) sera notre hôte pour l'événement.
</p>
5. </div>

Ajouter à votre Calendrier

Aussi sur l’article BarCamp Albuquerque 3, je fournis un lien aux utilisateurs pour qu’ils puissent ajouter l’événement à leurs programmes de calendrier :

Ce lien pourrait être une URL directe vers n’importe quel fichier iCalendar (à savoir, .ics, .ical, .ifb, .icalendar) avec votre information d’événement. En ce qui me concerne, j’ai utilisé le Service de Fils d’Evénements de Technorati.

En utilisant la technologie de Technorati, vous faites précéder simplement l’URL de la page où réside votre microformat avec http://feeds.technorati.com/events/, et puis utilisez l’URL résultante comme la valeur href de votre lien (<a>) :

<a href="http://feeds.technorati.com/events/http://www.ablognotlimited.com/articles/barcampalbuquerque-around-the-corner"
title="Télécharger le fichier .ics ">
Ajoutez à votre calendrier</a>

Quand un utilisateur sélectionne ce lien, le fichier .ics est créé dynamiquement et il peut le télécharger ::

Les Apparences Comptent

Je l’ai répété plusieurs fois : le marquage importe peu (bien qu’il devrait idéalement être valide et sémantique).

Et même si les valeurs class (propriétés/sous-propriétés) sont essentielles pour le microformat, la CSS que vous utilisez pour styliser votre information hCalendar est uniquement dédiée à la présentation (pas pour dire que ce n’est pas important).

Je recommanderais néanmoins d’utiliser les valeurs class qui sont requises par hCalendar dans votre CSS, plutôt que d’ajouter de nouvelles classes pour le style. Ceci vous donne simplement une CSS plus maigre.

Pour un exemple sur la façon dont vous pouvez styliser un calendrier d’événements, jetez un oeil au superbe travail de Jeremy Keith qu’il a produit pour des calendriers en cascade.

Pour finir, vous pouvez produire tout ce que votre coeur désire. La présentation de votre hCalendar ne se limite qu’à vos talents en CSS.

Pourquoi s’en Soucier ? Les Avantages, Bien Sûr

Bien qu’ayant déjà traité des avantages dans cette série d’articles, ils valent toujours la peine d’être répétés, … essentiellement parce que les microformats sont si simples à mettre en oeuvre et qu’ils offrent tant de potentiels.

Je souhaiterais que plus de personnes les connaissent et les utilisent. Cela aiderait à accroître le nombre d’outils et d’applications qui les utilisent.

Une Fois de Plus : Sémantique

Oui, la sémantique. Vous devez croire que c’est mon concept favori. Oui, vous auriez raison.

Les microformats prennent les standards existants, comme les éléments XHTML, et ajoutent encore même plus de valeur sémantique au contenu qu’ils contiennent. Ceci aide de mon point de vue les auteurs web à créer de meilleurs sites qui deviennen t plus utilisables et accessibles tant pour les humains que pour les machines (comme les moteurs de recherche).

Pour aller plus loin, le fait d’adopter la sémantique (même sans microformats, mais dans le marquage en lui-même) fait partie du support des standards ; des moyens standardisés de développer des sites. Ceci profite non seulement aux utilisateurs (et ceci concerne aussi les machines), mais assi aux designers/développeurs et aux équipes. Cela profite à tous.

Et, une fois de plus, ces approches posent une fondation (sémantiquement riche) pour Le Web Sémantique, tout en nous permettant simultanément de tirer profit du web et des technologies d’aujourd’hui.

Cool Shit

Je comprends tout à fait que la sémantique et les standards relèvent pour certains de discussions philosophiques. En fin de compte, soit vous « captez » ou non.

Si vous êtes dans le dernier camp, considérez quelques-uns des outils plutôt cools et utiles disponibles aujourd’hui qui savent tirer profil du microformat hCalendar.

Extensions Navigateur

Il existe tout un paquet d’outils navigateurs qui extraient l’information hCalendar provenant d’une page web de façon à pouvoir l’exporter et l’utiliser dans des applications qui supportent iCalendar.

• L’extension Operator pour Firefox extrait l’information hCalendar et vous permet de l’ajouter dans votre application préférée de gestion de calendrier (elle fait de même avec l’information hCard pour votre carnet d’adresses) :
  
• Aussi pour Firefox, l’extension Tails Export détecte l’information hCalendar (tout comme pour hCard) et l’extrait pour l’exporter dans votre application de calendrier :
  
• Le plugin microformats pour Safari fonctionne comme les extensions Firefox, en extrayant pour vous l’information hCalendar (et hCard) afin de l’ajouter à votre programme de calendrier.
• Le bookmarklet microformats extrait lui aussi l’information hCalendar que vous pouvez exporter dans votre application de calendrier :

Autres Services

• X2V de Brian Suda est une feuille de style XSLT qui extrait l’information hCalendar provenant d’une page web pour créer un fichier iCalendar .ics.
• Technorati offre un moteur de recherche de microformats qui indexe l’information microformatée (hCalendar, hCard et hReview) provenant d’URLs proposées et rend cette information disponible pour la recherche.
• Elias Torres a créé un script Greasemonkey hCalendar + Google Calendar Reminders qui identifier l’information hCalendar sur une page web et fournit une icône pour ajouter cet événement à votre Calendrier Google.
• Un autre script GreaseMonkey de Les Orchard vous permet de modifier les champs de formulaire texte de Firefox pour devenir des générateurs hCalendar : Magic Microformat Forms.

Il existe encore plein d’implémentations hCalendar que je n’ai pas mentionnées.

Pression Par les Pairs

Si ces ressources ne vous ont pas fait tourner la tête, alors peut-être qu’un peu de pression par les pairs le fera. Bon nombre de services leaders aujourd’hui utilisent hCalendar (et d’autres microformats) :

• Le site d’événement de Yahoo, Upcoming utilise hCalendar, de façon à ce que pendant que les utilisateurs naviguent dans les événements, ils puissent aussi les importer dans leurs applications de gestion de calendrier.
• MapQuest Local supporte aussi hCalendar, tout comme les microformats hCard et celui de géolocalisation.
• TripIt utilise le marquage hCalendar pour ses itinéraires.
• Last.fm utilise hCalendar pour ses annonces de concerts.
• Le géant du réseau social, Facebook, utilise hCalendar pour l’information d’événements.

Et il existe encore plus d’exemples hCalendar dans la jungle…

Bon, vous savez que vous voulez y aller. Essayez tout simplement. Croyez-moi, vous aimerez.

Outils pour une Production Plus Facile

Aussi, si j’ai pu parvenir à vous « vendre » les microformats, vous pourriez être ravi(e) de savoir qu’il existe quelques outils qui vous faciliteront la vie pour les implémenter (à l’inverse du codage à la main, sans mentionner le fait de se rappeler de toutes les propriétés/sous-propriétés) :

• Le hCalendar Creator est un formulaire qui génère du marquage hCalendar et les propriétés/sous-propriétés que vous lui proposez. Copiez et collez. Ne pourrait pas être plus simple.
• Pour Textpattern, vous disposez du plugin pnh_mf et de JMC_Event_Manager pour ajouter du contenu microformaté à votre site/blog Textpattern.
• WordPress a aussi quelques plugins qui aident les auteurs web à ajouter des microformats à leurs blogs/sites WordPress : Structured Blogging (aussi disponible pour MovableType) et WP-Microformats.
• Grâce à WaSP, il existe une extension microformats pour Dreamweaver conçue pour DW 8, MX et au-dessus.
• Le Conference Schedule Creator vous aide à créer un programme complet de conférence avec tous les événements marqués avec hCalendar.

A venir en 5ème Partie

Voilà c’est tout ce que j’ai pour hCalendar (est-ce assez ?).

La prochaine fois, dans Parvenir à la Sémantique avec les Microformats, 5ème Partie, je vous emmènerai en détail sur le microformat hAtom pour le contenu syndiqué comme les billets de blogs.

D’ici là …

♥ Share the Love

• ♥  Delicious
• ♥  Digg
• ♥  Ma.gnolia
• ♥  StumbleUpon
• ♥  Design Float
• ♥  Reddit

Note : Cette traduction s’inscrit dans la poursuite de travaux visant à mieux faire connaître les microformats. L’article original d’Emily Lewis a été publié le 1^er octobre dernier sur son blog personnel. Seul le lien original fait référence. Vous pouvez aider à raffiner cet article en éditant directement le code posé sur la page miroir de mon wiki-personnel. Merci d’avance. xtof