Emily Lewis : « Parvenir au Sémantique avec les Microformats – 7° Partie : Thèmes et Problématiques »

par xtof le 20 décembre 2009

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

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.

Share the Love

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.

{ 1 Commentaire… le lire ci-dessous ou en ajouter un }

Hubert alias dmsr juin 29, 2010 à 2 h 37 min

Il y a un argument simple pour convaincre de l’utilité des microformats: Google les prend en charge.
Je m’intéresse au SEO, et je doit dire que les Blogs SEO sont super chiant! ça tourne en rond, ce ne sont que des suppositions ou des évidences de bon sens! Et je crois sincèrement que Google à blinder son algorithme. Pour l’améliorer encore (car il a réussi à pas mal dé-polluer les résultats) il a besoin de métadonnées. Il veut savoir: qui (sommes nous)? vous en pensez quoi? où ça? quand ça? Marrant, ces données pour machines vont injecter plus d’humanité dans les résultats de recherche. J’ai hâte de voir les rich snippet se déployer. Il y a un combat qui se prépare: Rich snippet Google vs Like Bouton Facebook. Ce dernier est passé au devant de la scène mais l’Open Graph de FB avec sa trentaine de catégories (30/40 mots pour décrire le monde!) me semble un peu mal barré… Alors que Google joue l’ouverture avec en plus la prise en charge de 3 schémas: microdata, RDFa et microformats. Ma préférence va au 3ème.

Je suis arrivé ici car utilisateur de Drupal, j’ai fini par remarqué que WP faisait un meilleur usage des microformats (et la liste plus haut est ce que j’ai trouvé de mieux sur les plugins WP et les tutos de ce blog = le top de web francophone sur le sujet WP+uF). Mais en fait je me rends compte que c’est quand même pas terrible WP + uF, ya beaucoup de progrès à faire. Mis à part leur blogroll XFN que dal! & WP3.0 n’apporte rien de + en la matière. Un peu une imposture leur tag « microformats » du site WP. Il faut compter sur qqs plugins mais je crois que je vais perdre bcp de tps à les essayer… :(
Avec un pote on pense se faire un CMS simple basé sur du XML parsé en php/XSLT blindé de microformats (avec des sorties en RDF ou RSS/Atom) partout!
J’hésite… wordpress est super demandé quand même… avec de beau webdesign pas cher! mais je veux des uF partout moi aussi!

Laisser un commentaire

{ 2 rétroliens }

Article précédent :

Article suivant :