xtof » xtof

Facebook Ajoute les Microformats hCalendar et hCard à des Millions d’Événements

xtof — Fri, 18 Feb 2011 14:14:27 +0000

Encore une très grande nouvelle pour la communauté des microformats annoncée hier sur le blog officiel des microformats par Tantek. L’adoption par Facebook sur les pages événements du standard ouvert microformat hCalendar ouvre non seulement une facilité pour l’utilisateur de renseigner son agenda, mais laisse aussi présager de très riches potentiels pour les moteurs de recherche. Une réalisation de Paul Tarjan facilitée par Tantek avec un bug qui reste connu sur le fuseau horaire*. Tout ce qui suit n’est qu’une traduction du billet source et comme à l’habitude… seul le lien original fait référence.

Aujourd’hui, Facebook a marqué tous ses événements avec le microformat hCalendar en marquant aussi les lieux hCard. Selon une simple recherche sur Google, cela donne des millions d’événements publics publiés avec des microformats (si quelqu’un connaît un nombre plus précis pour la quantité totale du nombre d’événements Facebook, y compris les événements privés, ou combien d’événements sont créés par jour, faites-le nous savoir !).

Voici un exemple à venir : le Great British Booze-up durant SXSW 2011 (que je recommande vraiment si vous êtes impliqué dans le marquage de haute qualité, car un bon paquet d’entre nous seront là pour partager des verres et pour des conversations autour du panel du futur des microformats).

Visitez cette page dans un navigateur qui supporte les microformats (il existe à ce jour de nombreuses extensions pour Chrome, Firefox, Internet Explorer et Safari). Essayez par exemple Firefox 4 avec l’Extension Operator, et vous verrez s’afficher Évènements (1)” dans la barre d’outils. Un simple clic révèle “Great British Booze-up” que vous pourrez alors exporter dans votre agenda iCal, 30 Boxes, Google ou Yahoo.

Et si vous êtes un utilisateur, c’est tout. La capacité de copier des événements là où vous le désirez. Si vous publiez du hCalendar, Google les indexera et affichera des « rich snippets » pour vos événéments. C’est ce que les microformats vous « empuissancent » à produire.

Pour les auteurs/designers/dévéloppeurs web qui passeraient par là, jetons un œil sur le marquage de Facebook. Si vous regardez le code source de la page et cherchez “vevent”, vous voyez le code suivant :


 18:00 -

 21:00

Encoder des dates et des horaires qui fonctionnent tant pour les humains que pour les machines fût l’un des plus gros défis dans les microformats. Et ce que vous voyez ici est le résultat d’années d’itérations de communauté (techniques, feedback, recherche) appelé la technique ‘value-title’ du modèle de classe value. Pour faire court, en plaçant les dates et heures dans un format ISO lisibile par les machines dans l’attribut title d’un élément span vide innocent, adjacent à la date et l’horaire lisible pour l’humain, nous pouvons parvenir à un équilibre pragmatique entre l’expérience utilisateur, la fidélité du contenu en minimisant les effets consistant en fait à dupliquer la donnée (une violation du DRY, quelque chose que nous évitons du fait des incohérences potentielles à moins que ce ne soit absolument nécessaire pour un plus grand principe, tel que l’utilisabilité pour les humains).

C’est le déploiement le plus massif connu à ce jour de la technique ‘value-title’, et cela fonctionne merveilleusement avec le support du modèle de classe value dans Operator.

Jetons un oeil au lieu. Regardez le code source de la Sélection sur le bloc complet à partir de “Lieu Shakespeare’s Pub” jusqu’à “78701″ et vous verrez (de nouveau avec un ajout d’espaces blancs)


 Shakespeare's Pub 
 
 314 East 6th Street
 Austin, TX 78701

Ceci est un excellent exemple d’utilisation d’une hCard embarquée pour un lieu dans un événement hCalendar, à part une chose :

   Austin, TX 78701

Qui devrait être plus marqué comme :

Austin,
TX
78701

Je suppose que ce qui se passe ici est une interface grossière entre un système backend et frontend, ce qui revient à dire que pour la facilité, les développeurs peuvent retrouver la totalité de la ville, de l’état et du code postal à partir d’un backend sous une chaîne unique. Par conséquent, le mieux que puisse faire le front end est de marquer la chose en entière comme la ville (locality).

Même si ce n’est pas idéal, cela n’est pas horrible. Une fois de plus, en utilisant Operator, choisissez « Exporter le Contact »” pour Shakespeare’s Pub, et remarquez que ce qui s’affiche dans votre carnet d’adresses est tout simplement bien (même si les champs ne sont pas exactement aux bons endroits). Copier et coller cette adresse sur un site de cartographie fonctionne aussi. Le marquage n’est pas idéal, mais il est utilisable et utile. Et je suis heureux que Facebook ait fait le choix d’aller de l’avant et prennent cette décision pragmatique, tout en sachant qu’ils pourraient itérer et améliorer la fidélité des données dans une mise à jour à venir.

Le déploiement de hCalendar dans Facebook est simplement la dernière de leur série de support lent et régulier des standards ouverts et des microformats en particulier. Il y a deux ans Facebook avait ajouté le support de hCard à ses profils utilisateurs. L’année dernière, ils annonçaient le support de OAuth 2.0, tout comme l’ajout du support XFN rel-me aux profils utilisateurs, s’interconnectant ainsi avec le web social distribué. Ils ont fièrement documenté leur usage de HTML5. Et désormais, des millions d’événements hCalendar avec des lieux hCard. Impatient de voir ce qu’ils supporteront la prochaine fois.

Well done Facebook, and keep up the good work.

* Comme le faisait remarquer Andy Mabbett, il leur reste encore un peu de boulot afin d’être utilisable en Europe. En France, ce serait cool de localiser le fuseau horaire d’hiver à UTC/GMT+1 pour ne pas déraper de +9 heures dans l’espace-temps de nos agendas en ligne.

Rich Snippets de Google : Amélioration de l’Outil de Test, Fils d’Ariane et Evénements

xtof — Wed, 15 Sep 2010 11:23:39 +0000

En attendant l’intégration de descriptions enrichies sur les pages de résultats de Google en France pour présenter de vraies exemples, vous trouverez ci-dessous une traduction à des fins d’étude personnelle pour de futurs enrichissements documentaires avec des microformats… Dans ce billet « Rich snippets: testing tool improvements, breadcrumbs, and events » posté le 2 septembre dernier, Kavi Goel et Pravir Gupta de l’équipe Search Quality chez Google, présentent les améliorations de l’outil de test des fameux Rich Snippets évoqués par Tantek en juillet dernier. Belle perspective pour encourager l’adoption des microformats.

Depuis le lancement des rich snippets en 2009, les webmestres ont montré beaucoup d’intérêt à ajouter du marquage dans leurs pages web pour améliorer leurs présentations dans les résultats de recherche. Quand les webmestres ajoutent un marquage utilisant des microdata, microformats ou RDFa, Google sait comprendre le contenu des pages web et montrer des descriptions enrichies de résultats de recherche qui embarquent mieux l’information sur la page. Grâce à l’adoption incessante par les webmestres, nous voyons désormais plus de 2 fois plus de recherche avec des « rich snippets » dans les résultats aux USA, et une croissance multipliée par 4 depuis un an. Voici les trois mises à jour récentes.

Améliorations de l’outil de Test

Malgré un taux d’adoption encore faible à cette heure, l’implémentation correcte des rich snippets demeure un défi majeur. Pour aider à résoudre ce problème, nous avons ajouté de nouveaux messages d’erreur sur l’outil de test des rich snippets afin de vous aider à mieux identifier et réparer tous les problèmes avec le marquage.

Vous avez ajouté du marquage dans le passé mais n’avez pas vu apparaître les rich snippets pour votre site, nous vous encourageons à essayer de nouveau le test du marquage sur l’outil de test mis à jour.

Marquage des Rich snippets markup pour les fils d’Ariane

L’année dernière, Google annonçait une modification des résultats de recherche pour commencer à présenter les hiérarchies de sites (aussi appelés « breadcrumbs » ou « fil d’ariane ») plutôt que des URLs standards dans les cas où cela pourrait aider les utilisateurs à mieux comprendre un site web.

Nous ajoutons désormais le support pour le format de marquage des Fils d’Ariane qui permet aux webmestres d’identifier explicitement la hiérarchie du fil d’Ariane sur leurs pages.

Si l’interface-utilisateur du fil d’Ariane s’affiche déjà sur votre site, nous continuerons à la montrer même si vous ne produisez pas le marquage, aussi ne vous souciez pas de toute interface-utilisateur qui disparaîtrait. Notez que ce nouveau format peut être modifié ou remplacé à l’avenir. Comme avec tous les autres types de « rich snippets », alors que le marquage nous aide à mieux comprendre le contenu de votre site, cela ne garantit en aucun cas que l’interface-utilisateur s’affichera pour vos pages web dans les résultats de recherche.

Evénements

En janvier dernier, nous avons ajouté le support des rich snippets pour les événements. Si une page web contenant des listes d’événements s’affiche dans les résultats de recherche, jusqu’à trois liens vers des événements spécifiques pourraient être présentés dans la description enrichie sur la page de résultats de recherche. Ceci fonctionne bien pour les requêtes générales comme les [concerts à seattle], mais nous avons voulu aussi améliorer l’expérience de recherche quand on cherche un événement spécifique. Nous afficherons désormais les « rich snippets » quand les pages contenant un événement unique s’affichent dans les résultats de recherche. Les « rich snippets » d’un événement unique contiennent maintenant la date et le lieu de l’événement :

Pour les instructions sur l’ajout d’un marquage d’événements, référez-vous à la page events dans la documentation rich snippets (NDT : Si vous optez pour les microformats, aidez-vous de l’article de référence d’Emily Lewis concernant le marquage hCalendar avec le « modèle de classe value« .)

Microblogging : StatusNet est prêt pour tester le SWAT0 !

xtof — Sat, 11 Sep 2010 12:37:00 +0000

Très optimiste aujourd’hui sur le futur de mes Protocoles de Communication…

Je suis en train de réduire mon usage du courrier électronique. Regardez svp mes Protocoles de Communication.

Contexte Personnel sur les Protocoles de Communication

Avec 14397 messages non lus, ma boîte à courriels devient source de harcèlement quotidien, de perte de temps et de bruit sur mon téléphone mobile et autre tablette tactile. Heureusement à l’aide de filtres et de la nouvelle fonction « priority-box » de Google, je parviens à réserver et « suivre » ma messagerie pour mes amis, ma famille et d’autres usages strictement professionnels. Pour les relations avec mon premier cercle d’amis et ma famille, je rêve néanmoins de trouver des protocoles plus simples, plus efficaces et surtout plus conviviaux pour communiquer. Oui, je rêve simplement un jour de pouvoir écrire à ma fille -résidente sur Facebook et Twitter- à partir de ma propre plateforme de microblogging sans être contraint de créer un compte fantôme sur ces nouvelles plates-formes conversationnelles qui émergent au quotidien. Et ce à l’aide d’une syntaxe simple et interopérable comme nous l’avions sur l’email… du type @lucie.ducamp@facebook.com ou plus largement @nomutilisateur@votredomaine.fr… Avec des trucs magiques embarqués qui sachent aussi m’éviter de saisir ou hériter de champs « Objet » -se périmant dans les longues discussions- tout en me restituant proprement le contexte conversationnel des bribes de messages courts cohabitant sur différents domaines.

A entendre les bruits du web, nous n’y sommes pas. Mais les choses avancent très sérieusement et nous avons toutes les raisons d’être optimistes grâce à la contribution dans l’ombre de quelques géants du Web très affairés pour construire le « Web Social Fédéré » et son économie attenante.

Ce billet tente de décrire une première brèche enthousiasmante démontrant la perspective de commencer à briser quelques murs et parapets existants entre les plus grands silos sociaux. (Pour ceux qui l’ont vécu, souvenez-vous des murs entre AOL et Compuserve, et relisez aussi chez mon ami @fred pourquoi AOL serait le père de Twitter.)

SWAT0 : une première brèche dans le mur ?

Sur son micro-blog personnel -propulsé par Falcon-, Tantek rapportait mi-juillet un premier scénario d’usage sur le futur de nos échanges numériques sur les plateformes de microblogging :

we (@daveman692 @evanpro + I) just came up with a #fsws Social Web Acid Test (SWAT) v0 draft. full description, challenge: user A takes a photo of B from their phone and posts it, B gets notified that they are in a photo, C who follows A gets the photo and leaves a comment, A and B get notified of the comment, where users are on at least 2 (ideally 3) different services each of which is built with a different code base. drafted here: http://federatedsocialweb.net/wiki/FSWS2010_Next_Meeting_and_FSWS2011 – challenge: 2+ pieces of software that pass this test by 2010-09-30.

Le message peut vous sembler crypté… Mais il a été décrit avec de vrais prénoms de 3 géants du web. Le cas d’utilisation à produire avant la fin du mois est le suivant. Faites un dessin au besoin pour tenter de suivre ce scénario d’usage que vous retrouverez sur la page SWAT0 sur le wiki officiel du Web Social Fédéré :

Avec son téléphone, Dave prend une photo de Tantek et la dépose en utilisant un service web
Dave tague la photo avec Tantek
Tantek reçoit un avis sur un autre service qu’il a été marqué dans une photo
Evan, qui est abonné à Dave, voit la photo sur encore un autre service
Evan ajoute un commentaire sur la photo
David et Tantek reçoivent des notifications qu’Evan a ajouté un commentaire sur la photo

Note : Un cas d’usage très pratiqué dans les réseaux fermés. 2 personnes conversent autour d’un objet social : la photo. Et une personne amie (Evan) s’immisce dans le dialogue. Dans ce cas d’usage, l’idée est qu’à la différence de nos pratiques sur les « walled garden », les 3 personnes disposent bien de 3 domaines différents et parviennent à échanger.

Pour tenter de nous éclairer, Chris Messina a publié quelques dias pour présenter une première variante :

SWAT0 (variant flow)

Je vous laisse apprécier. Cette présentation pouvait rester confuse et faire mal à la tête aux néophytes non programmeurs comme moi ! D’après ce que je peux comprendre en gros, la bonne nouvelle est que nous avançons sur la bonne voie pour décloisonner les conversations sur le web. Plusieurs personnes présentes sur différentes réseaux sociaux pourraient enfin parvenir à se suivre les unes les autres sur un Web Social Fédéré, tout comme ce fût le cas pour l’interopérabilité de l’e-mail.

Sur le blog StatusNet, James Walker, Senior Services Architect annonçait hier officiellement que StatusNet est prêt pour tester SWAT0. Cette nouvelle est fascinante pour le futur de notre Graphe Global, aussi vous trouverez ci-dessous, une traduction rapide de son billet faisant état du point à date sur l’effort en cours. Considérons ce post pour spécialistes comme une invitation à jouer sur StatusNet. (Comme à l’habitude, seul le lien original fait office de référence)

StatusNet Prêt pour Tester SWAT0 !

L’un des résultats les plus enthousiasmants provenant du Federated Social Web Summit en juillet dernier fût la formulation du Social Web Acid Test – Level 0 (ou SWAT0). Impliqué dans un groupe de développeurs excités et enthousiastes pour construire un web social fédéré, nous nous sommes fixé une date limite au 30 septembre 2010 pour implémenter un premier scénario d’usage basique. Le cas d’usage contient un ensemble de suivis, citations, réponses – les types d’actions habituels que nous faisons sur les réseaux sociaux actuels – et se déroulant sur trois réseaux sociaux différents. Pour les détails complets, regardez en anglais la description du SWAT0.

Avec la sortie de la version StatusNet 0.9.5, nous sommes prêt à faire des tests SWAT0 avec d’autres développeurs. Le screencast ci-dessous démontre le flux SWAT0 entre trois installations séparées StatusNet utilisant OStatus. Nous invitons tous les hackers, fans et amateurs du Web Social Fédéré à commencer à tester leurs implémentations contre les nôtres !

Nous aimerions continuer à utiliser la liste de discussion OStatus pour résoudre les workflows avec d’autres développeurs OStatus.

Prêts à expérimenter SWAT0 ? Commençons par Pratiquer

Que dire de plus ? Je suis convaincu que pour comprendre, nous devons commencer par pratiquer. Les nouveaux arrivent à petit pas. Ludovic vient de nous rejoindre avant-hier sur sa propre plateforme avec l’identifiant @ludog@status.ubuk.fr et nous amorçons quelques premiers échanges entre deux domaines différents pour parler de « Grande Soupe« . Oui, j’en conviens, le design et l’interface demeurent encore sales. Mais en attendant des experts CSS prêts à peaufiner des interfaces pour nos futures tablettes tactiles, puis je vous encourager à faire votre propre installation sur votre domaine si vous êtes experts ou plus simplement ouvrir votre compte sur le Cloud StatusNet pour commencer à jouer et tenter l’expérience. Et tout prêt à aider pour expérimenter le scénario d’usage du dessus, bricoler proprement quelques connexions avec vos comptes existants chez Twitter et Facebook voire vous aider pour suivre à distance quelques-unes des plateformes interopérables.

Un ScreenCast SWAT0 en français ?

Merci d’avoir lu et rendez-vous à la fin du mois pour un premier compte-rendu expérimental. Le message étant difficile à faire passer, je rêverais de produire un screencast plus clair et moins « geek » en français. Une production simple avec de vraies exemples dans la vie (des personnes, les objets et capteurs plus tard !) avec l’adjonction de quelques interfaces mobiles (téléphones et tablette). Si vous disposez de votre propre instance StatusNet et si l’expérience du ScreenCast vous tente, faites-moi signe sur @xtof@status.net.

Mises à jour microblog le 2010-09-09

xtof — Thu, 09 Sep 2010 06:54:00 +0000

China #microblog overview http://bit.ly/aXAZME (feb 2010) #
@theliuyan Coucou ! currently discovering Sina. awaiting some videos of #tedxshanghai http://bit.ly/bOfanP #
@PhilJ : une première proposition d'agenda avec 1 invitation pour @harscoat ? mais ça coupe à 2min. http://bit.ly/d1VLz3 #
@harscoat es tu dispo mercredi prochain pour un livecast video avec @PhilJ – sujet prop : introduire le concept du #qs en #fra ? in reply to harscoat #
Rectif lien sur Café du Web http://bit.ly/cDaJS3 pour 1 Live video avec @harschoat (Zurich) et @PhilJ (SF) – #quantifiedself #
@OlivierAuber si ça te dit, si t'es par là ? … un coucous au bistro des 2 gares avec @nicolas2fr d'ici 20 min : http://bit.ly/aplcD6 bise in reply to OlivierAuber #
#plan GreenDrinks avec Parking Day (Les Colonnes) Fri, Sep 17, 2010, 7:00pm http://planca.st/9lb #
@ParkingDayFR Pour info http://planca.st/9lh #
@nicolas2fr #memo : tu organises un dîner avec Arnaud B. -> inviterai bien @groovyk à notre brainstorm ? bonne journée. #
@zoupic #doodle 1 – @tunglerocks sinon tu délaisses @zoupic@statusnet ? in reply to zoupic #

Mises à jour microblog le 2010-09-08

xtof — Wed, 08 Sep 2010 06:54:00 +0000

Brainstorm @Community_Space sur la mort du #PointPuissant @prezi et #switchprezi ? http://bit.ly/9e2Str – avec-vs des ex. corporate #fra ? #
@thegiao2001 yes. chaussée mouillée & oublié de #quantter #kiss 1 #sleep 8h #bike 5.9km – la bise & à toi de jouer : http://scr.bi/9ktVXa in reply to thegiao2001 #
Comment intégrer les statuts de vos amis dans vos préz ? "Twitter Live" en Flash avec @prezi : http://flic.kr/p/8yWVDx – des alternatives ? #
@schiste merci, mis en #gtd 1 pour intégrer tous types de flux #opendata dans des slides standards. #kiss 1 in reply to schiste #
Remembering 9/11. Give a Tribute To A Friend To Remember 9/11 At: http://bit.ly/dyqDb5 Pls RT #

Mises à jour microblog le 2010-09-07

xtof — Tue, 07 Sep 2010 06:54:00 +0000

Inscription au Meetup Potrepreneur du 9 septembre à Paris. http://lnkd.in/thN9Qc #

Mises à jour microblog le 2010-09-06

xtof — Mon, 06 Sep 2010 06:54:00 +0000

Une histoire de passerelles ? Extension #WordPress "Twitter Tools StatusNet " – Test Twitter -> #StatusNet http://flic.kr/p/8yjFv5 #
@harscoat Merci. Meeting à renouvler… tu trouvers fred sur @dumeny Bon week-end. Impatient de voir le dashboard #quantter en action ! in reply to harscoat #
@harscoat cool impatient de #quantter sur #statusnet et ailleurs P.I. un bricolage en cours avec ta pomme http://flic.kr/p/8yjbhe in reply to harscoat #
RT @francis_dierick: Pssst … I hear there's a new video on http://blog.quantter.com. Don't tell anyone #quantter #quantifiedself #
"the sad evolution of wikis" http://bit.ly/bVYN4Y /via @ffixx #

Mises à jour microblog le 2010-09-05

xtof — Sun, 05 Sep 2010 06:54:00 +0000

Loved final version of @xindanwei (New Work Unit) videopitch http://youtu.be/C-lij6q_bP0 – @theliuyan is a muse for @Community_Space ! #
Inspiring : InstrucTables, the first #opensource restaurant in the world http://instructablesrestauran … http://xtof.status.net/notice/47339 #
Plutôt que de lever des fonds… « Trouvez l’éléphant avec une épine dans le pied » ! http://bit.ly/9uAwNH /by @jxo #entreco #startup #cash #

microformats.org a 5 ans : 2 Milliards de Pages Avec des hCards, 94% de Rich Snippets

xtof — Sat, 10 Jul 2010 08:16:34 +0000

Traduction d’un billet microformats.org at 5: Two Billion Pages With hCards, 94% of Rich Snippets publié par Tantek le 8 juillet 2010. Seul le lien original fait référence.

La communauté microformats.org a récemment fêté son 5ème anniversaire ; plus de 5 années de recherche ouverte, de création et d’itération sur les standards du web pour exprimer une sémantique commune conçue d’abord pour les humains, puis pour les machines.

2 milliards de pages avec des hCards

Premier brainstorming en septembre 2004 et rapidement adopté par de nombreux outils, sites petits et grands, le nombre de pages publiées avec une ou plusieurs hCards a récemment passé le cap des 2 milliards il y a quelques jours selon Yahoo Search Monkey, rendant ce format le plus populaire pour les personnes ou organisations sur le web :

Les résultats de Search Monkey tendent vraiment à fluctuer, même heure par heure, aussi vous pouvez voir différents chiffres, plus bas et au fil du temps de plus en plus hauts. Voici quelques déploiements récents de hCard ayant sans aucun doute contribué à faire passer la barre des deux milliards :

1. Basecamp ajoute les hCards : personnes et sociétés

Il y a quelques jours, Jason Zimdars de 37 Signals rapportait que Basecamp avait été mis à jour pour supporter les hCards pour les personnes et sociétés, et étudie actuellement d’autres usages :

I’m pretty happy with this added functionality so I intend to explore using hCards in other parts of our apps where it makes sense.

Merci à Jeremy Keith pour avoir fait la demande et relancé 37 Signals.

2. Tous les domaines.tel supportent désormais hCard

Et tout juste hier, Telnic a annoncé que tous les noms de domaines .tel supportent désormais le microformat hCard

3. Plus de 14 millions de profils Gravatar en hCard

Il y a environ un mois, Gravatar de chez Automattic a lancé des profils publics et reliables pour tous les utilisateurs de WordPress.com users, magnifiquement présentés et marqués avec hCard, regardez par exemple le profil de Beau Lebens :

C’est un autre paquet de plus de 14 millions de hCards (chiffres de WordPress.com), chacune représentant un blogueur individuel sur le web public.

4. Plus de 20 millions de hCards Brightkite

Pour finir, juste avant le 5° anniversaire, le 20 juin dernier, les développeurs de BrightKite nous ont informé qu’ils avaient pleinement implémenté hCard sur l’ensemble de leurs 5,5 millions de profils utilisateurs et leurs 16,5 millions de pages d’endroits. Soit 22 millions de nouvelles hCards. Merci Brighkite pour ce cadeau d’anniversaire !

94% de marquage en rich snippets

Tous ces déploiements proviennent de la puissante combinaison de 1. facilité de publication des microformats (le moyen le plus facile pour marquer sémantiquement des personnes, lieux, etc. en HTML) et 2. le fait que des moteurs de recherche comme Yahoo et Google indexent les microformats et les rendent visibles sur leurs interfaces utilisateurs.

En mai 2009, Google lançait les Rich Snippets avec le support des microformats et RDFa, avec un ensemble de partenaires de contenus comme Yelp qui ont tous choisi d’utiliser les microformats pour produire des « rich snippets » dans les résultats de recherche de Google.

Démarré l’année dernière avec le support de hCard, hReview, hReview-aggregate et hProduct, Google a aussi rajouté le support de hCalendar et hRecipe.

Pour tout ça, Google a fourni des exemples comparés pour chaque type de snippet dans plusieurs formats (microformats, RDFa, microdata), ce qui a aidé à démontrer combien les microformats étaient plus simples/faciles à beaucoup d’égards (et de la promesse que les microdonnées montrent pour une extensibilité plus générale).

Comme le rapportait récemment ReadWriteWeb, Google signalait récemment lors de la Conférence Semantic Technologies que quand Google trouve des données sur les pages pour des rich snippets, 94% des fois, cette donnée de rich snippets est marquée avec des microformats (40.091 vs. 2.514, une estimation conservatrice supposant qu’aucune de ces pages ne contiennent les deux, s’ils l’avaient fait, le chiffre de 94% serait même plus élevé).

Crédit photo : Read Write Web: Google’s Semantic Web Push: Rich Snippets Usage Growing.

Les chiffres comparant hCard vs d’autres marquages alternatifs sont stupéfiants :

~30x plus de snippets sur les personnes utilisant hCard (33.675 vs. 1.160).

Ce n’est pas une surprise, comme le présentait l’étude « The State of Web Development 2010″ qu’il y ait bien plus de développeurs web (6x plus) qui utilisent les microformats dans leur travail quotidien (34.52% utilisent les microformats vs 5.63% qui utilisent RDFa, selon l’étude).

Compte tenu du fait qu’il y ait bien plus de développeurs qui utilisent les microformats, il n’est pas surprenant que Google trouve plus de microformats que d’alternatives. Ce qui est intéressant néanmoins, c’est qu’avec 6x plus de développeurs qui utilisent des microformats, Google trouve 16x plus de microformats pour les rich snippets que d’alternatives.

On pourrait conclure de ces deux chiffres que les développeurs utilisant les microformats sont 2-3 fois plus productifs en termes de nombre de pages produites avec des rich snippets. Cette productivité pourrait s’expliquer parce que les microformats sont plus faciles (prennent moins de temps) à implémenter, et par conséquent Google doit les reconnaître.

Rendre les Micoformats Encore Plus Simples

A nouveau, nous pouvons faire encore mieux. Et non, je ne parle pas simplement de passer de 94% à + de 99%.

La slide de présentation de Google faisait remarquer que les résultats étaient tirés d’un échantillon d’un million de pages sur Internet.. Parmi lesquelles seulement ~40,000 avaient des microformats. Compte tenu du fait que presque chaque page web mentionne des personnes, organisations, événements, ou tout autre microformat populaire, ce chiffre devait être bien plus élevé.

Par conséquent, il y a plein de pistes d’améliorations, et tout particulièrement sur les réactions provenant de Google, Yahoo, d’autres sociétés plus petites et de développeurs web indépendants, nous pouvons et devrions simplifier encore les microformats. Plus simples à écrire, et idéalement plus micro, avec moins de code, pour alléger les pages. Ayant démarré un brainstorming il y a quelques mois, il y a maintenant quelques types qui travaillent sur un “microformats 2.0″ pour parvenir à cet objectif.

Vous avez des réactions ou idées pour faire que les microformats soient même encore plus simples et plus faciles pour les auteurs ?

N’hésitez pas à ajouter vos réflexions à la page wiki microformats-made-simpler.

Avez-vous implémenté les profils hCard sur votre site ?

Ajoutez votre site à la page Profils utilisateurs supportant hCard.

Merci encore à tous pour le travail et les contributions de tous dans la communauté microformats pour cette cinquième année des plus excellentes. Hâte de voir même encore plus de succès pour notre sixième année.

Intro au HTML5 : Structure

xtof — Sun, 04 Jul 2010 19:18:01 +0000

Après avoir lu trop rapidement quelques articles de référence et localisé hier un diaporama de Tantek, c’est décidé, je me jette à l’eau pour étudier le marquage de ce site en HTML5. Attention néanmoins, seule la spécification du W3C à l’état de « working draft » fait office de référence. Ce premier billet d’une série à venir, définit les principaux éléments de structure du HTML. Le contenu, le code et les illustrations ont été tirés des éléments de l’excellent ouvrage Introducing HTML5 de Bruce Lawson et Remy Sharp à paraître la semaine prochaine. L’ouvrage est disponible en prévisualisation sur Safari Books. Les illustrations et traductions des contenus extraits du livre sont sous copyright de l’éditeur et publiés sous Fair Use à des fins d’étude personnelle.

HTML5 : La Structure Principale

Bien que la majorité du HTML5 soit conçue pour produire des applications web interactives, il s’avère aussi très intéressant pour les fans de syntaxe HTML et de sémantique ; 28 nouveaux éléments ont surgi et peuvent être utilisés tant dans vos pages « statiques » traditionnelles que dans toutes vos applications de Gestion de Contenu et/ou plates-formes de blogs.

Ma première intention est de transformer la structure actuelle de marquage des

s vers un système sémantique utilisant les nouveaux éléments de structure

. Je me pencherai tout particulièrement sur la manière dont les documents HTML5 disposent d’une structure prêtant moins à confusion pour les moteurs de recherche.

L’idée sur ce site sera d’avancer au fil de l’eau pour produire une structure de document s’orientant vers quelque chose de CHIC (ou POSH.)

Allons-y les mains dans le code.

Vous devrez tout d’abord ouvrir votre éditeur de code pour entrer un DOCTYPE et quelques informations préliminaires.

Le

Tout d’abord, le DOCTYPE :

Fait. Pas d’URLs compliquées à copier et coller. Adieu les numéros de version HTML et vieux héritages du DOCTYPE SGML. Non sensible à la casse, vous pouvez aussi écrire « doctype html » tout en minuscules ou panacher. Oui c’est tout.

Poursuivons à présent par l’encodage de caractère du document. Ne pas le faire peut provoquer des signes étranges dans l’affichage du document. Si comme moi, vous publiez essentiellement en français, je vous recommanderai pour faire simple d’utiliser l’encodage UTF-8.

Fait. Maintenant passons au contenu :

Mon super projet de blog
Aujourd'hui j'ai bu deux bières avec du camembert au petit déjeuner. 18 heures plus tard, je me suis couché.

Si nous validons ce blog des plus consternants, nous trouverons qu’il valide, bien qu’à ce stade il n’ait ni balise ni et ni (Figure 1.1).

Figure 1.1 : Cela peut paraître étonnant, mais même sans balises head, body ou html ce document valide :

Sans doute l’un des moments les plus intrigants des premiers pas en HTML5. Ces trois éléments manquants sont complètement optionnels, parce que les navigateurs les supposent. Néanmoins, ce n’est pas recommandé. En outre, la balise risque de porter confusion au lecteur d’écran, car c’est l’endroit où vous réglez la langue du document :

C’est important car le mot six, par exemple, se prononce différemment en anglais. Ainsi, comme nous le verrons plus tard, IE requiert l’élément avant de lui appliquer CSS pour styliser de nouveaux éléments HTML.

Ainsi, nous ajouterons ces éléments optionnels pour produire ce qui devrait être le minimum d’une page HTML5.

Mon super blog intéressant
Aujourd'hui j'ai bu deux bières avec du camembert au petit déjeuner. 18 heures plus tard, je me suis couché.

Est-ce que la validation importe encore à ce stade ?

Compte tenu de cette syntaxe qui sait pardonner, nous pourrions oublier des balises comme , , et , parce que le HTML5 définit un DOM cohérent pour n’importe quel marquage. Vous pourriez vous demander si la validation est importante ? Je pense que cette validation n’est toujours qu’un outil, c’est un moyen, pas une fin en soi.

L’objectif est un marquage sémantique : vous assurer que les éléments que vous choisissez font sens pour définir votre contenu, et ne décrivent pas la présentation. Il est possible d’avoir une page parfaitement valide constituée d’affichages de
s,
s et s, et qui soit sans aucun sens sémantique pour quiconque.

Mon point de vue est que cette validation demeure toujours une assurance qualité bien utile. Quand vous pilotez vos équipes de développement, leur faire passer la validation est une étape nécessaire avant toute correction de code. Un moyen de vous assurer que le code fait vraiment ce que vous voulez. Après tout, les navigateurs peuvent produire un DOM cohérent à partir d’une mauvaise syntaxe mais ce pourrait ne pas être le DOM que vous désirez.

Le validateur que j’utilise est http://html5.validator.nu accessible facilement par un favelet que vous trouverez sur cette page de Tantek. Nous attendons d’autres développements, comme des options pour forcer les choix de codage de manière à être avertis en cas d’absence de syntaxe XHTML, même si ce n’est pas requis par la spec.

Utiliser les nouveaux éléments HTML5 de Structure

En 2004, l’éditeur de la spec HTML5, a fouillé 1 milliard de pages web via le Google Index, pour savoir de quoi était constitué le “vrai” web. L’une de ces analyses publiées sur http://code.google.com/webstats/2005-12/classes.html était une liste des noms de classes les plus rencontrés dans ces documents HTML.

Plus récemment, en 2009, le crawler MAMA Opera (voir http://devfiles.myopera.com/articles/572/idlist-url.htm) a étudié les attributs de classe dans 2.148.723 URLs choisies au hasard et aussi dans des ids données aux éléments dans 1.806.424 URLs.

Table 1 : Noms de classes

Popularité   Valeur   Fréquence
1   footer   179,528
2   menu   146,673
3   style1   138,308
4   msonormal   123,374
5   text   122,911
6   content   113,951
7   title   91,957
8   style2   89,851
9   header   89,274
10   copyright   86,979
11   button   81,503
12   main   69,620
13   style3   69,349
14   small   68,995
15   nav   68,634
16   clear   68,571
17   search   59,802
18   style4   56,032
19   logo   48,831
20   body   48,052

Table 1.2. : Noms ID

Popularité   Valeur   Fréquence
1   footer   288,061
2   content   228,661
3   header   223,726
4   logo   121,352
5   container   119,877
6   main   106,327
7   table1   101,677
8   menu   96,161
9   layer1   93,920
10   autonumber1   77,350
11   search   74,887
12   nav   72,057
13   wrapper   66,730
14   top   66,615
15   table2   57,934
16   layer2   56,823
17   sidebar   52,416
18   image1   48,922
19   banner   44,592
20   navigation   43,664

Comme vous le constatez, une fois retirées les classes évidentes de présentation, il reste un bon paquet d’idées des structures que les auteurs essayent d’utiliser sur leurs pages.

Tout comme le HTML4 reflète le premier Web des scientifiques et ingénieurs (ainsi on trouve des éléments comme , , et ), le HTML5 est le reflet du web tel qu’il est durant son développements : 28 éléments sont nouveaux, bon nombre d’entre eux inspirés par les noms de classes ci-dessus, parce que c’est ce que les développeurs ont véritablement construit dans cette jungle.

Ainsi pendant que nous sommes d’humeur pragmatique plutôt que philosophique, utilisons-les. Voici un exemple de page de blog telle que nous la marquerions en utilisant l’élément sémantiquement neutre

Ma vie, mon oeuvre
Menu href="semaine-derniere.html">La semaine dernière Archives Hier Aujourd'hui, j'ai bu du thé au petit-déjeuner. 14 heures après, j'ai été me coucher. Mardi Plus de thé, aussi ai-je pris un jus de tomates pour le déjeuner. C'était du concentré. Les contenus sont sous copyright 2010 Bruce Sharp. Contactez-moi pour négocier les droits pour le scénario du film. .

En appliquant un peu de CSS, nous le styliserons ainsi :

#sidebar {float:left; width:20%;} .post {float:right; width:79%;} #footer {clear:both;}

Sous forme de diagramme, la page ressemblerait à ça :

Figure 1.2. La structure HTML4 de notre blog.

Bien qu’il n’y ait rien à redire sur ce marquage (et il continue à fonctionner parfaitement dans le nouvel HTML5), la plupart de la structure est complètement inconnu pour un navigateur, parce que le seul élément véritablement HTML que nous utilisons pour les repères sur ces structures de pages, c’est le
sémantiquement neutre (défini en HTML4 comme “un mécanisme générique pour ajouter de la structure aux documents”).

Il est possible d’imaginer un navigateur intelligent ayant une clé raccourcie qui irait droit vers la navigation de la page. La question demeure : Comment saurait-il où aller ? Quelques auteurs utilisent
, d’autres class= »nav » ou class= »navigation » ou class= »links » ou bon nombre d’autres équivalent dans des langues qui ne sont pas de l’anglais. Les tableaux ci-dessus suggèrent que menu, nav, sidebar, et navigation pourraient tous être synonymes.

Le HTML5 nous donne ainsi de nouveaux éléments qui ôtent toute ambiguïté sur les repères dans une page. Ainsi, nous allons récrire notre page avec quelques-uns de ces éléments :

Ma vie intéressante
Menu href="last-week.html">Semaine Dernière href="archive.html">Archives Hier Aujourd'hui, j'ai bu du thé au petit-déjeuner. 14 heures après, j'ai été me coucher. Mardi Plus de thé, aussi ai-je pris un jus de tomates pour le déjeuner. C'était du concentré. Les contenus sont sous copyright 2010 Bruce Sharp. Contactez-moi pour dealer les droits du film. .

Le schéma de la version HTML5 donnerait :

Figure 1.3. La structure HTML5 de notre blog.

Pourquoi pas d’élement ?

Il est aisé de voir comment notre saut hypothétique vers le raccourci de nav fonctionnerait, mais une exigence plus commune est d’aller droit vers l’aire de contenu principale. Quelques designers orientés accessibilité ajoutent un lien “skip links” tout en haut de la page, pour permettre aux lecteurs d’écran d’outrepasser les items de navigation. A cette heure en HTML5, il n’existe pas d’élément « content » à passer, aussi comment un lecteur d’écran (ou un moteur de recherche) saurait-il où démarre le contenu principal d’une page ?

En fait, il est simple de déterminer où il est : le premier morceau de contenu qui n’est pas ni dans un
,
,
ou
est le début du contenu principal, indépendamment du fait qu’il soit contenu dans un
, une
, ou que ce soit ou non un descendant directe de l’élément .

Bien que cela puisse sembler contre-intuitif de marquer les zones périphériques d’une page avec leurs propres éléments et non pas le coeur principal de la page -le contenu- parce qu’il peut être facilement découvert en excluant ces zones, il est mieux de ne pas ajouter un autre élément ; ajouter des éléments au langage n’est pas “libre” pour les constructeurs de navigateurs car cela rajoute de la complexité pour tester les suites et cela accroît les risques de régressions.

Avant que nous ne plongions plus en détails pour savoir quand utiliser ces nouveaux éléments, et ce qu’ils signifient, stylisons pour démarrer les structures basiques de la page.

Styliser le HTML5 avec CSS

Dans tous les navigateurs (sauf un), styliser ces nouveaux éléments est vraiment simple : vous pouvez ajouter de la CSS à n’importe quel élément, car comme l’énonce la spec, CSS “est un langage de feuille de style qui permet aux auteurs et utilisateurs d’attachez un style … à des documents structurés (c’est à dire des documents HTML et des applications XML)” et les applications XML peuvent avoir tous les éléments qu’elles veulent.

Bien que vous puissiez utiliser désormais les nouveaux éléments HTML5, la plupart des navigateurs —même les plus modernes— ne les comprennent pas nécessairement. Ils ne font rien de spécial avec elles et les traitent comme des éléments inconnus que vous produisez.

Par conséquent, en utilisant CSS, nous pouvons faire flotter
, placer des bordures sur
presque aussi facilement que nous le faisons avec des
s.

Ce qui pourrait surprendre les lecteurs, c’est que par défaut, CSS suppose que les éléments sont display:inline, par conséquent si vous réglez juste les hauteurs et largeurs des éléments structurels comme nous produisons les
s, cela ne fonctionnera pas correctement en l’état actuel des navigateurs jusqu’à ce que nous disions explicitement au navigateur que ce sont des display:block. Dans les navigateurs actuels, il existe une feuille de style rudimentaire intégré dans le navigateur qui outrepasse le style par défaut dans la ligne pour ces éléments que nous pensons comme de niveau-bloc par défaut (une telle feuille de style peut être trouvée sur
http://www.w3.org/TR/CSS2/sample.html). Néanmoins ces navigateurs n’ont pas encore de règles pour définir
,

,
, ; sous forme de display:block, aussi avons-nous besoin de spécifier ça dans notre CSS. Quand les navigateurs incluront véritablement de telles règles, notre ligne sera sans danger mais redondante, agissant comme une aide utile pour les anciens navigateurs. Par conséquent pour styliser notre HTML5 afin de correspondre à notre design HTML4, nous avons simplement besoin des styles suivants : header, nav, footer, article {display:block;} nav {float:left; width:20%;} article {float:right; width:79%;} footer {clear:both;} Et une magnifique page HTML5 est née. Exception faite dans un navigateur. Styliser CSS dans Internet Explorer Dans les versions actuelles d’Internet Explorer, votre page ne sera pas stylisée. En fait c’est pire : tous les nouveaux éléments ne sont pas stylisés, mais CSS est appliquée à ces élements HTML4 qu’IE supporte). La façon de cajoler IE pour qu’il applique CSS à HTML5 est d’utiliser JavaScript. Pourquoi ? C’est un secret, et si nous vous le disions, nous devrions vous assassiner. (En fait nous ne savons pas). Si vous ajoutez le Javascript suivant dans le head de la page : IE appliquera par magie les styles à ces éléments, compte tenu du fait qu’il existe un élément body dans le marquage. Vous avez seulement besoin de créer chaque élément une fois, peu importe combien de fois il apparaîtra sur une page. Souvenez-vous que HTML5 en lui-même n’a pas besoin de l’élément body, mais cette concoction d’IE8 (et versions antérieures), CSS et JavaScript le requiert. Note : l’élément n’a plus besoin que vous spécifiez le type de script ; JavaScript est supposé par défaut. Ceci fonctionne sur tous les navigateurs, aussi vous pouvez y aller directement. Bien que ce JavaScript ne soit pas nécessaire pour les autres navigateurs, il ne provoquera aucun dommage. Néanmoins, vous pourriez vouloir donner à votre page une optimisation en vitesse, et ne télécharger uniquement ce script dans IE en le contournant avec les commentaires conditionnels (voir instructions sur http://dev.opera.com/articles/view/supporting-ie-with-conditional-comments/). A chaque fois que vous utilisez un nouvel élément HTML5, vous aurez besoin de vous rappeler d’ajouter le document.createElement pour lui dans le . Alternativement, vous pouvez utiliser le petit script de Remy Sharp pour autoriser le HTML5 http://remysharp.com/2009/01/07/html5-enabling-script/ qui exécutera ceci pour tous les nouveaux éléments en une seule fois. Attention ! Les utilisateurs de toutes les versions d’Internet Explorer (actuellement IE8 et antécédents) auront besoin d’activer JavaScript pour que cette technique fonctionne, même si IE9 fonctionne comme les autres navigateurs et n’a pas besoin de JavaScript. Remarquez aussi que les modules d’impression d’IE ne semblent pas être affectés par notre JavaScript, ainsi les pages qui ne sont pas stylisés à l’écran n’embarquent pas ces styles vers l’imprimante. IE Print Protector (http://www.iecss.com/print-protector/) est un morceau de JavaScript qui vous permet d’imprimer des pages HTML5 dans IE… Note : voir l’article de Remy sur HTML5 doctor How to get HTML5 working in IE and Firefox 2? pour en savoir plus. Autres problèmes d’héritages dans les navigateurs Il y a d’autres problèmes d’héritages de navigateurs au moment de styliser HTML5. Dans quelques circonstances, régler une couleur d’arrière-plan sur les éléments ne fait rien à moins que vous ne déclariez explicitement la « background-color » à hériter sur les enfants, même si cela est supposé être le comportement par défaut. Dans quelques navigateurs basés sur Gecko, styliser les ancres de niveau bloc (ce qui veut dire, des éléments qui enveloppent les éléments de niveau bloc car HTML5 permet maintenant ça—voir billet à suivre, “Marquer le texte”) peut être problématique, et dans tous les navigateurs, vous devez explicitement déclarer de telles ancres à être display:block—voir http://mattwilcox.net/sandbox/html5-block-anchor/test.html. Nous ne pourrons pas proposer une liste exhaustive de ces comportements ; ce sont des problèmes temporaires qui devraient disparaître au fur et à mesure des nouvelles versions. Si, en tant qu’early-adopter, vous veniez à croiser de tels bugs, vous pourriez vouloir envoyer un rapport de bug. John Resig a publié un bon article pour faire ça : “A Web Developer’s Responsibility”chez http://ejohn.org/blog/a-web-developers-responsibility/. Quand utiliser les nouveaux éléments de structure HTML5 ? Nous avons utilisé ces éléments pour marquer notre page, les avons stylisés, et bien que l’utilisation de chacun d’eux pourrait sembler évidente d’après les noms, il est temps de les étudier plus à fond. Dans notre exemple au-dessus, comme sur la plupart de sites, le header sera le premier élément sur une page, et il contient le titre du site, les logos, les liens retour vers la page d’accueil, etc. La spécification dit : The header element represents a group of introductory or navigational aids … Note: A header element is intended to usually contain the section’s heading (an h1–h6 element or an hgroup element), but this is not required. The header element can also be used to wrap a section’s table of contents, a search form, or any relevant logos. Analysons cela : la première chose à remarquer est que cet élément n’est pas obligatoire ; dans notre exemple au-dessus, il est superflu car il enveloppe uniquement le . Sa valeur est qu’il regroupe des éléments “introductory or navigational”, aussi voici un exemple plus réaliste : Mon superblog intéressant Beaucoup de sites web ont un titre et une tagline ou sous-titre. Pour masquer le sous-titre de l’algorithme de structure (faisant ainsi que l’en-tête principal et le sous-titre soient dans une unité logique ; voir billet suivant pour une discussion plus approfondie), le titre principal et le sous-titre peuvent se regroupe dans le nouvel élément : Mon blog intéressant Tiédeur, passions et jambons L’en-tête contient aussi la navigation. Ce peut être très utile pour des navigations concernant tout le site, tout spécialement sur des sites construits par des gabarits là où l’ensemble de l’élément pourrait provenir d’un fichier gabarit. Ainsi, par exemple, la navigation horizontale présente sur tout le site sur www.thaicookery.co.uk pourrait être encodée comme dans la Figure 1.4. Ecole de Cuisine Thai> Apprenez de chez vous l'authentique cuisine Thai Accueil Cours de Cuisine Contact Figure 1.4. le de www.thaicookery.co.uk. Bien qu’il ne soit pas obligatoire que le soit dans le . L’exemple de cuisine Thai pourrait tout aussi simplement être marqué avec dans le : Ecole de Cuisine Thai> Apprenez de chez vous l'authentique cuisine Thai Accueil Cours de Cuisine Contact Cela dépend essentiellement si vous croyez que la navigation globale du site appartient à l’en-tête global du site et des considérations pragmatiques pour l’application du style. Par exemple, mon site personnel a une très grande barre de navigation à gauche de l’aire de contenu, qui peut être bien plus grande qu’un billet. Placer dans le ferait qu’il serait très difficile de placer le contenu principal au bon endroit. Ainsi dans ce cas, la navigation globale du site est en dehors du , et c’est un enfant cousin du comme dans notre exemple précédent. Figure 1.5. Page typique avec navigation globale du site en dehors de l’aire du principal. Remarquez que nous ne créons pas seulement le principal de la page ; il peut exister plusieurs headers — nous verrons ça dans un prochain billet. Les paragraphes d’informations sont généralement groupés ensemble dans de plus grandes sections telles qu’un chapitre de livre, un billet de blog ou un article de magazine. Le HTML5 fournit l’élément pour grouper ensemble des contenus, que ce soit des paragraphes, des images, des titres, … afin de former une unité cohérente plus grande. Les éléments s peuvent contenir un header et un footer, et peuvent aussi contenir tout élément pouvant être contenu dans le corps d’un document HTML. L’élément peut contenir aussi de l’information plus spécifique, ou des métadonnées, en utilisant les attributs « class » ou « id ». Un livre par exemple a le plus généralement plusieurs chapitres, ainsi nous pourrions marquer les chapitres en utilisant . L’élément n’est pas conçu pour remplacer l’élément qui fait encore partie du HTML5. Les éléments ne devraient être utilisés que quand ils sont appropriés sémantiquement. Pour de plus amples éclairages et quelques exemples d’utilisation, consultez l’article « the element » sur HTML5 Doctor. L’élément est conçu pour marquer la navigation. La navigation est définie comme des liens autour d’une page (ainsi par exemple, une table des matières en haut d’un article qui lie vers des ancres sur la même page) ou dans un site. Mais chaque ensemble de liens n’est pas une ; une liste de liens sponsorisés n’est pas une . Ni une page de résultats de recherche, tout comme le contenu principal de la page. Tout comme pour les s et s (et tous les nouveaux éléments), vous n’êtes nullement restreint à un par page. Vous pourriez tout aussi bien avoir un pour tout le site dans un header, un qui soit une table des matières pour l’article en cours, et un en-dessous avec des liens vers d’autres articles en rapport sur votre site. To or not to ? La spec suggère que les liens “légaux” (copyright, contact, liberté d’information, respect de vie privée, etc.) souvent balancés dans le footer ne devraient pas être enveloppés dans un : It is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases, without a nav element. Nous ne sommes pas d’accord avec cette suggestion. Beaucoup de sites placent un lien vers l’information d’accessibilité qui donne de l’information comme savoir où demander de l’information dans des formats alternatifs, et les personnes qui ont besoin d’une telle information sont celles qui auraient le plus avantage à ce que les agents utilisateurs puissent les emmener directement aux éléments marqués comme . Les contenus d’un élément seront probablement une liste de liens, marqués sous forme de liste non ordonnée (ce qui est devenu une tradition depuis l’article de Mark Newhouse « Domptage de Listes » ou dans le cas d’une barre de navigation « petit poucet », une liste ordonnée. Notez que l’élément n’est qu’une enveloppe ; il ne remplace pas les éléments ou , mais les enveloppe. De ce fait, les navigateurs qui ne comprennent pas l’élément verront simplement l’élément liste et les items de liste, et ils se comporteront tout simplement bien. Bien que cela fasse sens d’utiliser une liste (et cela vous donne plus de points d’ancrage pour CSS), ce n’est pas obligatoire. C’est parfaitement valide : Accueil A propos Vous pouvez aussi inclure les en-têtes pour la navigation : Navigation principale A propos Actualités Grouper et d’autres éléments dans une barre latérale Beaucoup de sites ont une barre latérale qui contient plusieurs blocs de navigation et d’autres de contenus non navigationnels. Prenons par exemple mon propre site www.brucelawson.co.uk (Figure 1.6). Figure 1.6. La barre latérale de mon blog, mixant navigation avec colophon et images de bellâtres La barre latérale à gauche du contenu principal a pleins de zones de (non représentées) telle que des pages, des catégories et les commentaires les plus récents. Ceux-ci sont marqués comme une série d’éléments (un unique contenant une liste avec une sous-liste est aussi possible mais je préfère utiliser des éléments discrets pour chacun des types de nav). Les éléments contenu dans le nouvel élément « peuvent être utilisés pour des effets typographiques comme des guillemets de citation ou des barres latérales, pour la publicité, pour des groupes d’éléments de navigation, et pour tout autre contenu considéré comme distinct du contenu principal de la page.” http://dev.w3.org/html5/spec/ Vue du code : Pages .. ... Commentaires Récents .. Blah Blah Hébergement Web par DreamHost Motorisé par WordPress Entrées (RSS) et Commentaires (RSS) Remarquez que la section “Blah blah” n’est pas marquée comme , car le lien vers mon hébergeur web, une photo de moi et deux liens RSS ne sont pas des « sections qui contiennent des blocks essentiels de navigation » comme le définit la spéc . L’élément est défini dans la spec comme représentant a footer for its nearest ancestor sectioning content or sectioning root element. (“Sectioning content” comprend les éléments article, aside, nav, section, et les éléments “sectioning root” sont blockquote, body, details, fieldset, figure, td). Remarquez que, comme avec l’élément header, il peut y avoir plus d’un sur une page ; nous revisiterons cela dans le prochain billet. A cette heure, nous avons simplement un footer sur la page qui est un enfant de l’élément body. Comme le dit la spec, When the nearest ancestor sectioning content or sectioning root element is the body element, then it applies to the whole page. La spec continue A footer typically contains information about its section such as who wrote it, links to related documents, copyright data, and the like. Notre contient de la donnée de copyright, que nous enveloppons aussi dans un élément . a été redéfini en HTML5 ; avant c’était un élément de présentation, mais en HTML5 il représente une petite impression : Small print typically features disclaimers, caveats, legal restrictions, or copyrights. Small print is also sometimes used for attribution, or for satisfying licensing requirements. Le de votre site a probablement plus qu’une simple notice de copyright. Vous pourriez avoir des liens sur la politique de confidentialité, l’information d’accessibilité (pourquoi cacher cela ?) et d’autres liens apparentés. Ceux-ci devraient être enveloppés dans , malgré le conseil de la spec (voir la section nav précédente). Vous pourriez même avoir un « fat footer » comme www.thecssdiv.co.uk (Figure 1.7). Figure 1.7. Le “fat footer” de thecssdiv.co.uk. Il est légitime d’envelopper les liens vers d’autres pages sur le site avec un élément à l’intérieur du footer—mais interrogez vous si fait partie du footer, ou s’il serait mieux pour aside d’être à la place un cousin du footer. Après tout, les liens vers d’autres pages sont supposés tangentiellement apparentés à la page principale plutôt que simplement le contenu du footer. Ici, j’utiliserais le marquage suivant : ... Twitter ... Flickr ... WeLoveLocal ... A venir ... ©2007 Ross Bruniges. Design par Blogging Tips et Pearsonified Figure 1.8 montre comment éviter un “fat footer.” Figure 1.8. Eviter un “fat footer” en faisant des liens externes un de la page globale Le contenu principal de cette page d’accueil de blog contient quelques billets de blog. Nous enveloppons chacun d’eux dans un élément . est spécifié ainsi : The article element represents a component of a page that consists of a self-contained composition in a document, page, application, or site and that is intended to be independently distributable or reusable, e.g., in syndication. Un billet de blog, un tutoriel, un article d’actualité, une bande dessinée ou une vidéo avec sa transcription correspondent parfaitement à cette définition. Remarquez que, comme pour , l’en-tête va à l’intérieur de l’élément, ainsi : Mon article Blah blah est incorrect ; ce devrait être : Mon article Blah blah Il y a bien d’autres facettes plus intéressantes pour qui sont disponibles dans le chapitre 2 de l’ouvrage à paraître Introducing HTML5″ en pré-commande chez amazon. Résumé Nous avons ainsi pu jeter un premier coup d’oeil au HTML5 et son DOCTYPE. Nous avons vu ses règles de syntaxe plutôt souples telle que la non sensibilité à la casse, l’omission possible de trucs standards comme type="text/javascript"/"text/css" sur le script, et les balises de style. Nous avons structuré les principaux repères d’une page web en utilisant header, footer, nav, aside et article, pour fournir aux agents utilisateur plus de sémantique que l’élément générique qui était la seule option en HTML4 et stylisé les nouveaux éléments avec la magie de CSS. Pas mal pour un début non ? A suivre dans un prochain billet pour une implémentation sur ce site. Introducing HTML5 Le HTML5 arrive et il est temps de s’y mettre. Ecrit par deux développeurs passionnés, ce livre vous présente par l’exemple comment utiliser ce langage que vous pouvez dès à présent sur vos sites personnels et professionnels. Plutôt que de se cantonner à une description académique de la spécification, il se concentre sur les problèmes que le HTML5 peut résoudre. Les parties des spécifications qui sont encore en train d’évoluer ou sont non implémentées sont discutées dans le contexte. Au travers d’exemples pratiques, vous apprendrez notamment comment bâtir des formulaires spéciaux, gérer la vidéo et l’audio, utiliser Canvas pour dessiner des lignes et des formes, les transformations et animations, de nouvelles options de stockage et bases de données web, sans oublier un bonus sur la géolocalisation et comment l’utiliser en HTML5. Cet ouvrage à paraître en juillet 2010 est destiné aux designers et développeurs HTML, mais pourra plus largement intéresser tous les auteurs curieux de comprendre l’avenir du web. A partir de 23.09 € chez amazon.