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. Un microblog dans le firewall xtof — Wed, 31 Mar 2010 07:32:09 +0000 StatusNet a été implémenté chez Molecular, une agence interactive pionnière aux Etats-Unis. Ce qui suit est la traduction d’un billet de Craig Andrews Microblogging inside the Firewall qui nous décrit les perspectives d’usage du microblog dans le Firewall. Les petites chaînes de texte sont un gros business – et ce qu’elles soient publiques ou dans le pare-feu. Comme nous le savons tous, Twitter est vraiment génial – les spots de publicité à la TV et la radio pour les plus grandes sociétés mentionnent leurs sites Twitter et même les cartes de visites font référence de nos jours aux URLs twitter. Mais Twitter ne peut pas être utilisé pour de l’information interne, aussi il y a beaucoup de puissance collaborative en latence prête à se déchaîner à l’intérieur du firewall de l’entreprise. Imaginez comment les salariés seraient plus productifs au quotidien s’ils pouvaient partager quelques petites bribes de connaissance. Imaginons par exemple cette timeline : Alice : Le client a adoré la présentation - nous avons gagné #ventes Bernard : Le distributeur de la machine à café du 27° étage fonctionne Charles : #CSS me rappelle une programmation orientée aspect #poa Denise: Le projet avance selon le planning #projet3 Eve : Chers collègues du #projet3 : notre politique front-end est-elle utile ? http://ur1.ca/shyu Fred : @eve Probablement - discutons-en avec @bernard au déjeuner Zoé : @fred @eve nous avons utilisé ces guidelines sur le #projet5 et ça a bien marché RobotDSI : le serveur email est en panne. La DSI a été contactée. Ces exemples montrent que : La barrière à l’entrée est vraiment basse (Alice a posté immédiatement après sa présentation client, probablement de l’avion) L’information d’affaires utile est échangée, tout comme le « team-building » (Bernard a fourni une information non professionnelle sur le distributeur que les autres apprécieront probablement) Le fait que la discussion soit ouverte à une plus large audience que l’email, d’autres participent de manière inattendue et bénéfique pour le groupe (regardez comment Zoé, qui n’est même pas sur le projet, a aidé l’équipe du projet3) Les robots peuvent publiciser l’information rassemblée automatiquement. Par exemple, le DSI pourrait installer un robot vers les serveurs de moniteurs et publier automatiquement les mises à jour de statuts. Les robots peuvent aussi s’abonner aux fils RSS en pontant les wikis et blogs avec le monde du microblogging. Il y a bon nombre d’autres avantages, une fois que la métadonnée est considérée. Les personnes choisissent qui suivre. Si Alice n’est pas intéressée par l’état des systèmes informatiques, elle ne s’abonne pas au RobotDSI. Les utilisateurs peuvent marquer un message comme favori. Les messages qui sont marqués comme favoris plusieurs fois s’affichent dans une liste « favoris », qui est une source géniale d’information utile. En cliquant sur un #projet3, Bernard peut trouver tous les billets concernant ce projet, en fournissant une option de recherche puissante. Les messages peuvent se voir attachés en option une information de géolocalisation. Les utilisateurs peuvent dire si la personne à laquelle ils parlent sont dans le même bureau qu’eux, travaillant de la maison, chez un client, ou une autre filiale de leur société. Cette donnée permet aux utilisateurs de prendre des décisions rapides sur leur façon de communiquer pour continuer (téléphone, email ou marche à pied dans les étages). Chez Molecular, nous avons voulu tirer partie de ce que le microblog « dans le firewall » avait à offrir, aussi nous avons évalué quelques outils privés de microblog, encherchant un logiciel qui fournisse une interface facile, permettant la personnalisation du « look and feel », et qui disposait de clients pour différents terminaux (comme en a Twitter). A la fin, nous avons choisi StatusNet. (Disclosure : je suis un développeur ayant contribué au projet StatusNet.) Le logiciel StatusNet (qui fait aussi tourner le site identi.ca avec environ ~200k utilisateurs) est Libre et Open Source aussi quiconque peut se sentir libre de l’installer, de l’évaluer et l’utiliser sans se soucier des contrats ou frais de licence. Néanmoins, StatusNet, Inc (la société qui supporte le logiciel StatusNet) offre des services professionnels si vous choisissez de faire fonctionner le logiciel sur site, ou de l’hébergement si vous préférez l’héberger ailleurs. Si la route “go it yourself” est sélectionnée, l’installation est vraiment immédiate car il fonctionne sur la pile bien connue LAMP et dispose d’une communauté vibrante prête à répondre aux questions. StatusNet peut intégrer un Annuaire LDAP et même quelques solutions simples de « Single Sign On ». Pas de soucis pour gérer les comptes au fur et à mesure des arrivées et départs des salariés, ainsi l’information privée reste privée. Le logiciel supporte aussi toute une variété de clients sur un bon nombre de plates-formes, en partant de Windows, Mac, Linux jusqu’aux terminaux iPhone et Android. Après avoir développé une skin personnalisée, sélectionné les extensions à autoriser et testé avec un petit groupe, nous avons officiellement lancé “IsoBuzz” la semaine dernière pour toute l’entreprise. Nous avons déjà vu des conversations intéressantes. Au fil du temps, nous espérons voir IsoBuzz devenir un outil puissant pour le partage de connaissance et la collaboration, tout particulièrement entre les bureaux distants et entre les départements. Emily Lewis : « Parvenir au Sémantique avec les Microformats – 8ème partie : Modèle-de-Classe-Value » xtof — Mon, 21 Dec 2009 18:14:41 +0000 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. Mise à jour : 20 octobre 2009 Tantek Çelik m’a demandé que j’ajoute des exemples dans la ligne du marquage modèle-classe-value dans cet article, afin que les personnes qui travaillent sur des applications pour parser les usages de ce modèle puissent référencer cet article comme un exemple live. Vous verrez ces exemples dans la ligne au-dessous, chacun d’eux étant indiqué sous une mise à jour. 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 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 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 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 : 6 juin 2009 à 18h30 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 ? 6 juin 2009 à 18h30 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. Mise à jour : 20 octobre 2009 Exemple dans la ligne du modèle de classe value ci-dessus, utilisant Test Evénement 1 6 juin 2009 à 18h30 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. 18 mai 2009 à 13h00 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. Mise à jour : 20 octobre 2009 Exemple dans la ligne du modèle de classe-value ci-dessus, en utilisant Test Evénement 2 18 mai 2009 à 13h00 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. 18 mai 2009 à 1 heure de l'après-midi . 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. Mise à jour : 20 octobre 2009 Exemple dans la ligne du modèle de classe value, spécifiant séparément la date et l’heure en utilisant Test Evénement 3 18 mai 2009 à 13h00 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 : 6 juin 2009 à 18h30pm 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. Mise à jour : 20 octobre 2009 Exemple dans la ligne du modèle de classe value, spécifiant séparément la date et l’heure en utilisant Test Evénement 4 6 juin 2009 à 18h30 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 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 : 18 mai 2009 à 13h00 Mise à jour : 20 octobre 2009 Exemple dans la ligne du modèle de classe value utilisant le sous-ensemble value-title avec un vide Test Evénement 5 18 mai 2009 à 13:00 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 : class="bday">Mon anniversaire est le 4 septembre. Mise à jour : 20 octobre 2009 Exemple dans la ligne du modèle de classe value au-dessus appliqué à bday dans la hCard Personne Un Mon anniversaire est le 4 septembre. Ou pour publier des dates dans hAtom : class="published">2 juin 2009 Mise à jour : 20 octobre 2009 Exemple dans la ligne du modèle de classe value au-dessus appliqué à published dans hAtom Test Post par Auteur Test 3 juin 2009 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 : mobile: 505-123-4567 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). Mise à jour : 20 octobre 2009 Exemple dans la ligne du modèle de classe value au-dessus appliqué au type tel dans la hCard Personne Deux mobile : 505-123-4567 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 : Home: +33 (0) 603 960 492 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. Mise à jour : 20 octobre 2009 Exemple dans la ligne du modèle de classe value au-dessus appliqué aux values tel séparées dans la hCard Personne Trois Home : +33(0)603 960 492 Mise à jour : 21 décembre 2009 NDT : En d’autres langues pour traduire « Home » en « Domicile » : Domicile : +33(0)603 960 492 Exemple dans la ligne du modèle de classe value au-dessus appliqué aux values tel séparées dans la hCard Personne Quatre Domicile : +33(0)603 960 492 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. ♥ Share the Love Delicious ♥  Digg ♥  Ma.gnolia ♥  Script & Style ♥  StumbleUpon ♥  Design Float ♥  Reddit Le modèle-de-classe-value xtof — Sat, 19 Dec 2009 14:11:19 +0000 Le modèle-de-classe-value résout deux des trois défis les plus importants que les microformats ont rencontrés durant toute leur histoire : l’accessibilité et la localisation. Après de nombreux mois d’itérations sur le sujet (recherches, brainstorming, test et documentation) menées par Ben Ward, la version du modèle-de-classe-value est prêt à l’utilisation et au support. Publication et implémentation Plusieurs auteurs ont déjà commencé à utiliser le modèle de classe value, y compris ce blog, et quelques implémentations ont déjà commencé à le supporter. Tous ceux qui publient du contenu marqué avec des microformats ou développent des implémentations microformats telles que des parseurs et outils de publication devraient étudier attentivement à supporter le « modèle-de-classe-value » dans le contenu qu’ils publient et sur les outils qu’ils implémentent. Tout particulièrement : Si votre implémentation parse hCalendar, hReview, or hAtom, implémentez SVP le modèle de classe value dans votre parseur, testez-le avec des exemples donnés à la fois dans la spécification et la liste croissante des exemples de modèle-de-classe-value dans la jungle, et ajoutez-les à la liste des implémentations modèle-de-classe-value. Si votre site publie hCalendar, hReview, ou hAtom, utilisez svp le modèle-classe-value pour vos dates et horaires, et ajoutez votre site à la liste croissante des exemples de modèle-classe-value dans la jungle. Si votre implémentation génère hCalendar, hReview, ou hAtom, générez SVP vos dates et horaires marqués avec le modèle-classe-value, et ajoutez votre implémentation à la liste des implémentations modèle-classe-value. A chaque fois que vous rencontrez un problème ou que vous avez quelque feedback concernant le modèle-classe-value, ajoutez-les respectivement sur les pages value-class-pattern-issues et value-class-pattern-feedback. Résolutions majeures et révisions mineures Le modèle de classe-value a adressé la majorité des problèmes d’accessibilité et de publication sur plusieurs microformats, tout particulièrement pour les usages typiques des dates et horaires. Néanmoins, il demeure encore quelques questions ouvertes sur des microformats spécifiques pour lesquelles nous continuons encore à explorer des solutions (plus sémantiques, plus accessibles), tout particulièrement le microformat geo (et la propriété de hCard) quand elle est spécifiée comme un unique hyperlien ou une abbréviation, et la propriété dtend de hCalendar quand elle spécifie une date complète (plutôt qu’un date-horaire spécifique). Avec le modèle-classe-value fournissant des solutions à deux des tois plus gros défis des microformats (le dernier des trois sera adressé dans son propre billet de blog), et les résolutions aux questions restantes substantielles (telles que mentionnées au-dessus) sur hCard, hCalendar, hReview, et hAtom, nous travaillerons sur les révisions 1.0.1 qui : incorporeront les problématiques substantielles résolues à cette heure exigeront le support du modèle-classe-value sont publiées pour une compréhension et une utilisabilité plus larges. Les auteurs de tous les microformats drafts, en développement et microformats composés à venir devraient aussi exiger le support du modèle-classe-value afin d’encourager une meilleure accessibilité dans le contenu qui est marqué avec des microformats. Remerciements Merci à tous ceux dans les communautés les plus larges sur l’accessibilité et l’internationalisation, qui ont maintenu l’effort avec leurs critiques constructives, leurs suggestions , leurs tests de cas, leurs documentations de résultats de tests et pour la participation générale. Vos efforts ont contribué à des améliorations majeures dans les microformats, et nous nous n’aurions pas pu faire ça sans vous et votre expertise. Tout particulièrement : L’article original du Web Standards Project hAccessibility de Bruce Lawson et James Craig qui a fourni à la fois une documentation détaillée des problèmes concrets du vrai monde qui ont été expérimentés du fait d’utilisation de l’élément abbr avec les microformats, tout comme plusieurs idées d’alternatives à explorer. Bon nombre de ces idées ont constitué la base sur laquelle la communauté des microformats a passé plusieurs mois à investiguer en profondeur, à itérer, à faire évoluer, parfois diminuer et raffiner dans ce que nous avons produit pour le modèle de classe-value (value-title en particulier). Tous ceux qui ont contribué aux documentations de modèles, questions, brainstorms, opinions concernant l’élément abbr, les dates, les datetimes, l’accessibilité, les technologies d’assistance, les internationalisation/localisation, etc. sur le wiki microformats. Tous ces ajouts à notre corps de connaissance nous ont aidé à raffiner le modèle-classe-value que vous voyez aujourd’hui. Je veux remercier tout particulièrement James Craig pour les nombreuses heures passées à tester intensivement et à la documentation de plusieurs alternatives avec des lecteurs-écrans. Personnellement, j’ai aussi beaucoup apprécié l’optimisme de Derek Featherstone concernant les microformats et l’accessibilité, nous encourageant à poursuivre nos travaux, et son soutien positif pour encourager la plus grande communauté de ceux qui utilisent le Web. Pour conclure, merci à tous les auteurs, designers et développeurs qui supportent les microformats, tout spécialement ceux qui ont continué à faire ainsi malgré les questions restant ouvertes sur l’accessibilité et d’autres problèmes, pour leur patience et leur ténacité. En rappport @microformats announcement of value-class-pattern Le billet d’appel à implémentations du modèle-classe-value” sur microformats-dev. Traduction d’un billet de Tantek publié en mai dernier sur le blog des microformats. Seul le lien original fait office de référence C.V. CHIC xtof — Sat, 14 Nov 2009 02:10:26 +0000 Toujours aussi dingue de microformats et avide de remettre en forme un vieux C.V. personnel, vous trouverez ci-dessous une traduction d’un article qui vous donnera tout ce qu’il faut pour construire un C.V CHIC. Par Emily Lewis, nouvelle gourou des microformats. Cet article d’Emily Lewis paru le 10 novembre 2008 traite en profondeur du hResume, un microformat conçu pour publier un joli Curriculum Vitae avec du HTML ayant du sens. Cette traduction est en cours et seul le lien original fait référence Emily Lewis – « Parvenir au Sémantique avec les Microformats : hResume » (Partie 6) J’ai démarré cette série il y a deux mois. Je voulais partager avec vous mon amour des microformats et détailler comment je les ai implémentés, avec l’espoir d’encourager plus de personnes à les adopter. A cette heure, j’en ai beaucoup couvert : Les microformats-basés-sur-rel dans la Partie 1 XFN dans la Partie 2 hCard dans la Partie 3 hCalendar dans la Partie 4 hAtom dans la Partie 5 Et maintenant, parce que je conclus cette série, il est temps de parler du microformat hResume qui est utilisé pour ajouter de la sémantique et de la structure aux résumés et CVs sur le web. hResume : le Contexte Avant de plonger dans le marquage et les détails du hResume, que penser d’un peu d’information de contexte ? Spécification Draft hResume est une spécification draft. Qu’est-ce que ça peut vouloir dire ? En fin de compte, elle n’a pas été approuvée officiellement. Et cela veut dire qu’elle peut (et le sera probablement) changer un peu jusqu’à ce qu’elle devienne une spécification formelle. Est-ce si important ? Peut-être pour vous, pas pour moi. J’accepte volontiers que la plupart des technologies web soient des cibles mouvantes. C’est tout bonnement la nature du web. Aucune raison pour moi de ne pas implémenter une technologie en laquelle je crois. Le Meilleur des Microformats hResume est, à sa base, l’un des microformats les plus simples, avec seulement huit propriétés. En même temps, hResume est un microformat composé ; il utilise trois autres microformats : rel-tag, hCard et hCalendar. Sur bien des points, ceci représente le meilleur des microformats : il utilise des standards existants. Et le Pire Ceci étant dit, la façon dont hResume utilise hCard et hCalendar était, pour moi tout du moins, confuse et frustrante. Peut-être est-ce dû au statut draft et que ce sera résolu avant l’approbation finale. Peut-être est-ce moi et mon incapacité à penser à mon contenu ré-utilisable dans le sens où cela est requis pour appliquer hCard et hCalendar. Quelle que soit la raison, hResume représente aussi le pire des microformats … de mon point de vue tout du moins. Ce n’est pas le hResume en lui-même que je trouve problématique en soi. C’est le manque flagrant d’information et de bonne documentation. C’est quelque chose qui je pense est une épidémie pour les microformats, en général, et spécifiquement le Wiki Microformats. Bien sûr, hResume est un draft, aussi est-il difficile de voir là beaucoup de gens partager de l’information à ce propos. Mais l’information wiki pour le hResume laisse vraiment à désirer. Je réalise combien c’est horrible de dire ça, tout spécialement parce que dois au wiki (pour ne pas citer ses auteurs et contributeurs) dette de gratitude pour me fournir toute l’information qui y réside. Mais le wiki est difficile à digérer, et épuisant au possible. Et quand il n’y a que très peu d’autres ressources pour le hResume, cela rend le processus d’implémentation du microformat pénible et frustrant. Mais c’est la raison pour laquelle je blogue sur les microformats, et j’espère que d’autres feront de même. Plus il y aura de personnes qui en parleront (que ce soit en bien ou en mal), meilleure sera l’information. Aussi, fini de pesert, avançons. Historique hResume a un historique très simple. A la différence de hCard, hCalendar et hAtom, il n’a pas de lien avec une technologie « précurseur ». Cependant, il a été développé sur la base de recherche de formats existants de curriculum-vitae tels que HR-XML et Europass. Les Fondamentaux Comme pour tous les microformats, il y a quelques « règles » que je mentionnerai (une fois de plus): Les propriétés et sous-propriétés sont exprimés en valeurs class. Ce sont elles qui définissent le microformat hResume. Les noms de 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 sous-propriétés. De ce fait est invalide. Le marquage utilisé est sans rapport avec le microformat (bien le marquage devrait être valide et sémantique). Le Profil Quand vous implémentez hResume, vous devriez vous assurer d’inclure son profil dans le : profile="http://microformats.org/wiki/hresume-profile/"> Comme je le mentionnais, hResume peut tirer partie à la fois de hCard et hCalendar. Aussi, si vous choisissez d’utiliser ces microformats supplémentaires dans votre hResume, vous devriez vous assurer tout autant d’inclure leurs profils.. Le W3C autorise plusieurs valeurs de profils (séparées par un espace blanc), aussi vous pourriez avoir tous les trois profils : Néanmoins, parce qu’à la fois hCard et hCalendar sont des spécifications formelles, elles sont incluses dans le profil URL combiné qui couvre tous les microformats non-draft. Je recommande d’utiliser ce profil unique, combiné avec le profil hResume : L’Exemple A la différence de tous les autres microformats traités dans cette série, je n’ai pas implémenté hResume sur A Blog Not Limited. Je ne vois vraiment pas de raison d’avoir mon résumé sur mon blog personnel, et en plus je l’ai déjà sur mon design portfolio. L’exemple qui suit est pris directement à partir de résumé sur mon portfolio. C’est plutôt un long paquet de marquage et d’information, aussi j’ai coupé ce qui est redondant en termes de hResume et l’ai remplacé par des ellipses. J’ai aussi retiré les valeurs class en rapport avec le style et n’ont rien à voir avec le microformat hResume. Si besoin, vous pouvez toujours voir le source de ma page en live. class="hresume"> class="contact vcard"> Emily Paige Lewis Albuquerque, NM 87106 USA eplewis[at]gmail[dot]com Design Portfolio LinkedIn profile Highlights of Qualifications class="summary"> Web designer specializing in hand-coded semantic XHTML, cross-browser CSS, progressive enhancement accessibility and usability Expert in the design of corporate web sites, intranets, email campaigns and e-commerce applications … Technical Expertise Web Design & Development class="skill" rel="tag">XHTML — 9 yrs class="skill" rel="tag" >CSS — 9 yrs … … Experience & Accomplishments class="experience vevent vcard"> Web Designer Pitney Bowes Business Insight December 2004 – present Designed interfaces and developed XHTML, CSS and graphics for main corporate site, international sites, marketing newsletters, corporate blog, corporate intranet and user conference site …
…
Education class="education vevent vcard"> Web Design & Development Certification George Washington University, Center for Professional Development September 2001–June 2003 GPA 3.8
…
Propriété Racine : hresume La propriété racine est hresume et elle est requise. Toute l’information hResume devrait être contenue dans un élément assigné class="hresume": class="hresume"> Propriété requise : contact hResume n’a qu’une propriété obligatoire, contact, qui indique le nom et l’information de contact pour le propriétaire du résumé. Elle ne peut être utilisée qu’une fois seulement. En outre, hResume requiert que l’information de contact soit une hCard : class="photo" alt="Emily Lewis" /> class="fn n" id="emily-hcard-name">class="given-name">Emily class="additional-name">Paige class="family-name">Lewis class="adr">class="locality">Albuquerque, class="region" title="New Mexico">NM class="postal-code">87106 class="country-name" title="United States of America">USA class="email">eplewis[at]gmail[dot]com class="url" rel="me">Design Portfolio LinkedIn profile Consolidation d’Identité Avec rel-me Remarquez aussi dans mon exemple que j’ai utilisé rel-me sur les liens vers mes sites web : rel="me">Design Portfolio rel="me">LinkedIn profile Comme je le détaillais dans la Partie 1, rel="me" est utilisé sur les hyperliens provenant d’une page d’une personne vers d’autres pages à propos de la même personne. Problématiques Avec address La spécification hResume recommande plus loin d’utiliser pour contenir l’information de contact sur la personne. Selon le W3C, l’élément est : « … Les auteurs peuvent employer l’élément ADDRESS pour fournir les informations de contact du document ou d’une partie essentielle de celui-ci, comme un formulaire.« Dans le cas d’un curriculum-vitae, est sémantiquement correct parce que l’information de contact est pour le propriétaire du résumé. Néanmoins, vous remarquerez que je n’utilise pas dans mon exemple (gasp !). Ceci parce que ne peut pas contenir d’éléments de niveau-bloc. Bien sûr, je pourrais remplacer tous les s et les avec des s, mais ceci fait bien moins sens sémantiquement parlant que de reconcer complètement à . Propriété Optionnelle : summary La propriété optionnelle summary indique l’aperçu des qualifications et objectifs. Elle aussi, ne peut être utilisé qu’une fois dans un hResume.. Dans mon résumé, je ne déclare pas un objectif, mais fournis une liste de qualifications : Highlights of Qualifications class="summary"> Web designer specializing in hand-coded semantic XHTML, cross-browser CSS, progressive enhancement accessibility and usability Expert in the design of corporate web sites, intranets, email campaigns and e-commerce applications … Propriété Optionnelle : skill La propriété optionnelle skill s’applique au contenu qui indique les compétences spécifiques d’une personne. skill peut être utilisé plusieurs fois dans un hResume. La spécification exige que le contenu skill soit contenu par un lien assigné class="skill" et rel="tag" : class="skill" rel="tag">XHTML — 9 ans class="skill" rel="tag">CSS — 9 ans … Folie de Lien Même si j’ai appliqué la propriété skill comme l’indique la spécification, je n’aime vraiment pas du tout tous ces liens supplémentaires. Je ne comprends vraiment pas pourquoi la spécification exige que soit appliqué ce lien à la propriété … pourquoi pas n’importe quel élément ? Tous ces liens supplémentaires semblent superflus sur un résumé. Et je ne suis pas convaincue qu’ils fournissent quelque valeur ajoutée, tout particulièrement pour un employeur potentiel. En fait, ce pourrait être une distraction pour quelqu’un intéressé pour en savoir plus à mon propos et sur mes qualifications professionnelles. Les Espaces de Tags Semblent Hors de Propos Un autre problème que je rencontre avec la spécification est qu’elle exige aussi un rel="tag" assigné sur les liens. Dans la Partie 1, j’ai expliqué que rel-tag indique la destination du lien est un tag (ou mot-clé) qui dit ce dont traite la page en cours — ou la partie de la page. En outre, rel-tag requiert que le lien de destination (href) inclut la valeur réelle du mot-clé comme segment final de la valeur d’URL. Ceci est connu sous l’expression « tagspace. » Compte tenu de ces obligations, tout mes liens skill sont dirigés vers Technorati, parce qu’il fournit de tels « tagsspaces ». Néanmoins, ceci fait que ces liens sont même encore plus hors de propos en ce qui me concerne. Si je dois maintenir tous ces liens, je préférerais beaucoup plus qu’ils aillent vers un endroit qui fournisse une information discrète sur le mot-clé, comme Wikipedia, mais il n’existe pas d’articles pour toutes mes compétences et je voulais au moins rester cohérente. En fin de compte, je pourrais changer les liens de destination vers des pages de Wikipedia quand elles seront disponibles et enlever tous les liens skill pour lesquels il n’existe pas d’article Wikipedia. Ou je pourrais décider de retirer complètement les liens skill. Ils sont optionnels. Propriété Optionnelle : experience La propriété optionnelle experience indique les diverses expériences professionnelles d’une personne. Elle peut être utilisée plusieurs fois. La spécification requiert que chaque « événement » professionnel soit un hCalendar et que chaque rôle/titre dans le travail soit une hCard : class="vcalendar"> Web Designer class="org">Pitney Bowes Business Insight class="dtstart" title="2004-12-01">December 2004 – present class="description"> Designed interfaces and developed XHTML, CSS and graphics for main corporate site, international sites, marketing newsletters, corporate blog, corporate intranet and user conference site …
…
Le Modèle Include : Eviter la Redondance
Le fait que la spécification requiert l’assignation d’une hCard pour tous les titres/rôles dans les emplois et le fait que hCard exige la propriété fn (le nom formaté de la personne), ceci voudrait dire que pour chaque experience dans mon résumé, je devrais lister pour toutes l’information sur mon nom.
Ceci n’a pas de sens et va à l’encontre du format/contenu attendu dans un résumé.
Heureusement, les types des microformats ont sorti le include design pattern, qui permet à la donnée provenant d’un endroit sur une page d’être utilisée dans d’autres endroits sur la même page.
En utilisant le modèle include, je peux inclure mon information fn à partir de mon contact hCard dans mon experience hCard et éviter de devoir la répéter.
Tout d’abord, j’ai dû assigner à mon information contact hCard fn un id que je peux référencer dans mon include :
id="emily-hcard-name">Emily Paige Lewis
Puis, pour toutes mes hCards experience, j’ai ajouté un assigné class="include" avec une valeur href égale au fn id :
Emily Paige Lewis Web Designer Pitney Bowes Business Insight December 2004 – present Designed interfaces and developed XHTML, CSS and graphics for main corporate site, international sites, marketing newsletters, corporate blog, corporate intranet and user conference site … …
Alternativement, le modèle include permet l’utilisation de plutôt qu’un lien. est vraiment plus sémantiquement correct que , néanmoins il provoque quelques problèmes d’affichage.
Dans Safari, par exemple :
Chrome fait la même chose avec les barres de défilement :
Opera n’affiche pas les barres de défilements, mais affiche une tonne d’espace blanc où demeure :
IE6 et IE7 affichent quelque chose (je ne sais pas comment l’appeler) pour le code :
Compte tenu de ces incohérences d’affichage, le lien est la méthode recommandée pour l’include pattern. A cette heure, trop de problèmes.
Bon, pas vraiment des « problèmes », juste quelque chose à garder à l’esprit : le lien doit avoir un contenu à l’intérieur qui puisse garantir l’accessiblité pour les lecteurs-écrants.
Ceci veut dire qu’il s’affichera sur le navigateur, ce qui n’écessite que j’utilise CSS pour masquer le contenu (via display:none) de manière à ce que le lien ne s’affiche pas plusieurs fois.
Datetime Design Pattern
Mise à jour : 02/06/2009 Le modèle-date-horaire est désormais déprécié en faveur du modèle-de-classe-value. Voir cet article en attendant la partie 8 de cette série pour en savoir plus sur ce nouveau pattern.
Pour chacun de mes « events » d’emploi, j’utilise hCalendar comme c’est recommandé. Ceci veut aussi dire que j’utilise le datetime design pattern pour mes dates de début et de fin :
class="dtstart" title="1999-11-01">Novembre 1999 – Janvier 2004
Ce modèle spécifie que l’élément contenant est un qui a une valeur d’attribut title qui renvoie une information date-horaire « lisible-par-une-machine » alors que l’information contenue (et qui s’affiche dans les navigateurs) est une information date-horaire « lisible-par-les-humains ».
En outre, le datetime design pattern spécifie que la valeur title devrait être exprimée dans un format ISO 8601.
Comme je le detaillais dans la Partie 4, il existe des problématiques d’accessibilité concernant le datetime design pattern qui doivent être encore résolues.
Propriété Optionnelle : education
La propriété optionnelle education indique les « événement » education telles qu’une scolarité étudiante.. education peut être utilisé plusieurs fois dans un hResume.
Tout comme pour experience, la spécification demanque que chaque « évenément » education soit un hCalendar. Et bien que cela ne fasse pas partie de la spécification, j’ai aussi ajouté de l’information hCard pour chaque institution :
class="vcalendar"> class="summary">Web Design & Development Certification class="org fn">class="url" title="Link opens off this site">George Washington University, Center for Professional Development class="dtstart" title="2001-09-01">Septembre 2001–class="dtend" title="2003-06-01">Juin 2003 GPA 3.8
Ce Que Je N’ai Pas Utilisé
hResume supporte aussi l’information d’affiliation et de publication. Je n’ai utilisé aucune des ces propriétés dans mon résumé parce qu’elles ne sont pas pertinentes en ce qui me concerne (à cette heure). Mais voici quelques exemples sur la façon dont je pourrais les implémenter.
Propriété Optionnelle : affiliation
La propriété optionnelle affiliation indique les organisations avec lesquelles une personne est affiliée. affiliation peut être utilisé plusieurs fois dans un hResume.
La spécification requiert que l’organisation contenue dans affiliation soit une hCard :
class="fn org">Association pour le Développement du Marketing class="fn org">Groupe des Utilisateurs Adobe
Publications
hResume n’a pas de propriété spécifique pour les publications. Au lieu de cela, la spécification recommande l’utilisation de pour indiquer les publications qu’une personne a écrites :
"Choisir Votre Caisse de Retraite", New OD, Septembre 1998
Outils Pour Vous Faciliter la Vie
Ceci couvre la totalité de hResume. Maintenant, comment vous faciliter la vie pour faire ça vous-même ? Il existe quelques outils pour vous aider à implémenter hResume :
hResume creator génère un hResume extrait de l’information proposée. Le « hResume Project » a créé un plugin hResume pour WordPress. Emurse offre quelques gabarits qui génèrent hResume.. LinkedIn génère des hResume pour l’ensemble de ses 9 millions de profils publics. CV Antix est un constructeur de CV/Résumés dynamique et basé sur le web. Resolio crée tous les résumés dans le format hResume.
Autres Outils
Il existe un plugin hResume LinkedIn pour WordPress qui extrait le contenu du hResume à partir d’un profil public LinkedIn, qui peut ensuite être ajouté à une page WordPress. Brian Suda a une version beta d’un outil hResume to resume XML tool. Le transformeur microformats Optimus fournit un transformateur de hResume vers JSON, XML ou RSS.
Malheureusement, je n’ai pas pu trouver quelque agrégateur ou extratcteur de hResume, même si j’ai vu mentionner que SimplyHired utilise hResume pour agréger les CV’s des chercheurs d’emploi. Hélas, je n’ai pas pu trouver quelque information spécifique à ce propos, ni n’ai vu quelque hResume sur le site.
Je n’ai pas trouvé non plus quelque plugin ou extension navigateur, fait intéressant, une ancienne version de l’extension Firefox Tails supportait hResume. Mais ça ne fonctionne pas avec la version actuelle de Firefox.
A un certain niveau, ce manque d’outils me surprend et ne me surprend pas.
Comme je râlais au début de cet article, l’information disponible sur hResume est minimale et pas vraiment facile à digérer. En outre, hResume est un draft. Cela ne me suprend aucunement que les types n’aient pas investi trop à développer des outils pour lui.
J’espère que cela changera.
Avantages
Pour moi, quand quelqu’un me demande pourquoi j’utilise des microformats, la réponse est simplement « Pourquoi ne le ferais-je pas ? » Les standards, la sémantique et les microformats sont tous bien dans mon monde.
Mais voici juste quelques avantages du hResume et des microformats pour ceux ayant besoin d’être convaincus.
Standardisation & Innovation
hResume fournit un moyen standardisé pour les personnes de maîtriser leurs donnés de curriculum vitae, ce qui représente une fondation demandée pour des outils et technologies innovantes.
Si les job boards devaient adopter hResume, cette standardisation veut dire que le contenu hResume pourrait être hébergé et mis à jour en un endroit, et puis pingué vers les job-boards quand il y a des mises à jour.
Cette standardisation fournit aussi les fondations pour les personnes de disposer de CVs riches et utiles qui pourraient être facilement cherchés par des employeurs et/ou clients potentiels.
Sémantique & Simplicité
hResume ajoute de la structure et du sens au contenu des CVs et les rend à la fois lisibles par les humains – et les machines. Tout cela avec des standards existants pour le marquage et les données.
Et malgré mon combat personnel pour implémenter hResume, il est intentionnellement simple. Juste quelques noms de classes pour le marquage et hResume est en place.
C’est Tout ?
Bon, c’est tout ce j’ai pour hResume. Mais ce n’est pas vraiment la fin de cette série.
J’ai un article en plus : une conclusion où je prévois de discuter de ce que j’ai appris durant le processus d’écriture de cette série.
Je prévois aussi de traiter d’accessibilité, de sémantique et de standards (encore). Et une brève discussion sur le débat vs. RDF » est en route. Et tout ce qui pourra m’arriver.
Ce sera tout à cette heure. …
Mise à jour : 7 décembre 2008
Jia Mi a traduit cet article en chinois : 使用微格式来丰富网站语义：hResume.
Je ne lis pas le chinois, aussi je ne peux garantir la traduction. Mais l’intention est belle, aussi j’en fais la promotion.
Mise à jour : 1/08/2009
Jan Sládek a traduit cet article en Tchèque : Kódujme sémanticky s mikroformáty: hResume.
♥ Partagez l’Amour
Delicious ♥ Digg
Passez le mot !
Vous voulez partager cet article avec d’autres ? Utilisez SVP l’URL raccourci : http://tr.im/cvchic.
Et bien sûr, vous pouvez toujours tweeter ça. Lâchez-vous, y’a même de la microsyntaxe et un peu de monnaie libre…
Paramétrer Votre Mac pour du Développement Local en Utilisant Coda, WordPress et MAMP xtof — Mon, 05 Oct 2009 14:13:11 +0000 Ce billet est une traduction localisée (et testée) d’un article original de Jay Robinson qui pourrait bien m’aider dans le futur pour essayer une débauche de thèmes Wordpess. Et qui sait, envisager un jour de publier sur une plateforme CHIC…. WordPress n’est pas qu’une plateforme de blogs. Mais c’est aussi un système de gestion de contenu vraiment sophistiqué que vous pouvez utiliser pour développer et gérer des sites web de clients professionnels. Mieux encore, il est complètement gratuit. Pour démarrer vos expérimentations, ça peut être pratique et moins stressant de faire vos bricolages sans publier de fichiers sur internet. Vous trouverez donc ci-après un kit complet pour expérimenter en local sur votre Mac. Dans ce tutoriel, je décrirai comment paramétrer un fichier sur votre Mac que vous pourrez utiliser pour pratiquer la construction de sites web avec PHP et une base de données MySQL. Mais avant de démarrer, vous aurez besoin : d’un Mac d’un éditeur de texte d’un navigateur web Commençons : 1. Téléchargez WordPress à partir de WordPress.org (ou sur le site francophone pour une version traduite). Décompressez le fichier obtenu dans un dossier appelé « wordpress ». Renommez-le VOTRE_NOM_PROJET (le mien s’appellera « Projet Microformats » pour illustrer l’exemple). Glissez-le dans le dossier Sites que vous trouverez dans votre répertoire utilisateur. Pour un accès plus facile, j’ai ajouté le répertoire Sites dans le répertoire latéral de ma fenêtre du Finder : 2. Téléchargez le logiciel gratuit MAMP à partir de Mamp.info et installez la dernière version. MAMP veut dire Mac, Apache, MySQL et PHP. Cette application aide à gérer vos bases de données MySQL de manière directe et conviviale. Ouvrez l’application et cliquez sur “Preferences…”, puis sélectionnez l’onglet « Apache » pour sélectionner notre Document Racine. Nous voulons sélectionner le répertoire Sites situé dans le répertoire « Home ». Le chemin devrait lire /Users/VOTRE_NOM_UTILISATEUR_MAC_OS_X/Sites. Une fois MAMP activé, vous devez voir des feux verts. Testez-le pour voir s’il fonctionne en ouvrant votre navigateur et en allant sur http://localhost:8888/. Vous devriez voir les contenus de votre répertoire ~/Sites. Rappelez-vous que nous préparons un environnement de développement local. « Localhost » veut dire votre ordinateur, aussi personne d’autre dans le monde ne pourra voir ces fichiers dans son navigateur web. Bon, MAMP fonctionne, et MySQL attend juste de notre part que nous lui donnions quelques tables de bases de données. Allez sur http://localhost:8888/MAMP (doit être tout en capitales) puis cliquez sur “phpMyAdmin”. Une fois là, saisissez le nom de votre projet dans le champ « créer votre base de données » avec VOTRE_NOM_PROJET. Mon nom de base de données sera « ProjetMicroformats » pour coller à mon projet : 3. Maintenant, nous n’avons plus qu’à faire correspondre WordPress avec la base de données. Accédez à VOTRE_NOM_PROJET dans ~/Sites et renommez le fichier wp-config-sample.php en wp-config.php. Ouvrez le fichier pour éditer le contenu. DB_NAME veut dire nom de la base de données, aussi entrez VOTRE_NOM_PROJET. Les DB_USER et DB_PASSWORD sont tous deux réglés sur “root”. Laissez “localhost” pour le serveur, parce que le serveur est votre ordinateur local : 4) Visitez la page http://localhost:8888/VOTRE_NOM_PROJET et vous tomberez sur la fameuse installation de WordPress en 5 minutes. Paramétrez le nom du blog et l’e-mail, et on vous donnera un mot de passe. (Je copie et colle ce mot de passe généré pour rentrer dans WordPress, puis le change immédiatement vers quelque chose de plus facile à retenir. J’utilise un mot de passe simple pour tous mes sites de développement WordPress, parce qu’ils ne sont pas sur l’internet) : WordPress est configuré pour tourner sur votre ordinateur, mais ne sera accessible que localement. La dernière étape est de paramétrer Coda pour accéder au répertoire. 5) Allez sur Coda, cliquez sur le bouton Sites (commande 1) et cliquez sur “Add Site…” (tout en bas de la fenêtre). Si vous développez localement, ceci sera utilisé simplement pour générer une vignette afin de voir votre projet dans Coda. Ce peut être la même URL, par exemple : http://localhost:8888/VOTRE_NOM_PROJET Nickname VOTRE_NOM_PROJET Remote Root Laissez ce champ tranquille Local Root Vous pouvez utiliser le bouton « Set » du navigateur pour trouver votre répertoire projet dans le répertoire Sites, ou copier et coller ce modèle : /Users/VOTRE_NOMUTILISATEUR_MAC_OS_X/Sites/VOTRE_NOM_PROJET Connecting, Terminal and Source Control Laissez ces champs. Vous ne devez pas les configurer pour le développement local.
Je veux un blog hAtomique ! xtof — Sun, 04 Oct 2009 19:54:28 +0000 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 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 des pages web qui incluent le microformat : 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 : 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) : Exemple : Billet Unique Bon, assez parlé des origines. Voici comment j’implémente hAtom sur ma page de contenu avec l’article complet : class="hentry"> class="entry-title">L'Accessiblité Web Est Importante class="published" title="2008-08-28T13:14:37-07:00">28 août 2008 rel="tag">Commentaires Quelque chose à ajouter ? class="entry-content"> The National Federation of the Blind v. Target lawsuit was settled this past Wednesday on the following key terms: … Tags: rel="tag">accessibility rel="tag">standards rel="tag">web design 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 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 . 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 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 pour hCard. Comme je le précisais dans la 3ème Partie, l’utilisation de pour une hCard n’est valide que si la hCard est pour le propriétaire du document. La FAQ hCard déconseille d’utiliser 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, 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 . 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 : 28 août 2008 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 Mise à jour : 02/06/2009 Le modèle-date-horaire est désormais déprécié en faveur du modèle-de-classe-value. Voir cet article en attendant la partie 8 de cette série pour en savoir plus sur ce nouveau 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 Ce pattern spécifie que l’élément conteneur est un 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 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 () 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 : rel="bookmark">L'Accessibilité Web Est Importante 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 () 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 » : rel="tag">Commentaires rel="tag">web design 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 : class="hentry"> class="entry-title">rel="bookmark">Web Accessibility Is Important class="published" title="2008-08-28T13:14:37-07:00">Aug 28, 2008 rel="tag">Commentaries class="entry-content"> The National Federation of the Blind v. Target lawsuit was settled this past Wednesday on the following key terms: … rel="bookmark">Continue Reading Tags: rel="tag">accessibility rel="tag">standards rel="tag">web design class="hentry"> class="entry-title">rel="bookmark">Plateau class="published" title="2008-08-27T13:59:51-07:00">Aug 27, 2008 rel="tag">Commentaries class="entry-content"> 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. rel="bookmark">Continue Reading Tags: rel="tag">exercise rel="tag">fitness rel="tag">push ups class="hentry"> class="entry-title">rel="bookmark">Getting Semantic With Microformats, Introduction class="published" title="2008-09-05T07:05:34-07:00">Sep 5, 2008 rel="tag">Commentaries class="entry-content"> I'm an organizer with a sometimes frustrating need to pay attention to the smallest details. … rel="bookmark">Continue Reading Tags: rel="tag">French translation rel="tag">hAtom rel="tag">hCalendar … 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 ). 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/) : Fil Atom pour A Blog Not Limited 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 !
Emily Lewis : « Parvenir au Sémantique avec les Microformats, 4ème partie – hCalendar » xtof — Sat, 18 Oct 2008 15:53:24 +0000 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, 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 des pages web qui contiennent le microformat : 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 : 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 : 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 : class="vevent"> Oui, c'est un billet court, mais marquez ça dans vos agendas : class="url summary"> class="category">BarCamp Albuquerque 3 aura lieu ce week-end. Quand : class="dtstart" title="2008-09-13T09:00:00">13– class="dtend" title="2008-09-14T18:00:00">14 septembre, à partir de 9h00 jusqu'à 18h00 les deux jours. Où : class="location vcard"> CJW Cafe à 4801 Alameda Blvd NE , Albuquerque, NM 87113 Quoi : class="description"> Un évènement de class="duration" title="P2D">deux jours 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. 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 . 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 ( , , , , etc.) la 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 : Oui, c'est un billet rapide, mais à marquer dans vos agendas : BarCamp Albuquerque 3 c'est ce week-end. dtstart La propriété dtstart décrit les date/horaire pour le démarrage de l’événement. Dans mon exemple, « 13″: class="dtstart" title="2008-09-13T09:00:00">13 – title="2008-09-14T18:00:00">14 septembre, de 9h00 à 18h00 les deux jours Date/Time Design Pattern Mise à jour : 02/06/2009 Le modèle-date-horaire est désormais déprécié en faveur du modèle-de-classe-value. Voir cet article en attendant la partie 8 de cette série pour en savoir plus sur ce nouveau pattern. Remarquez que l’élément contenant pour dtstart est un , là où l’information contenue est est « 13″ et la valeur d’attribut title est « 2008-09-13T09:00:00″: <abbr class="dtstart" title="2008-09-13T09:00:00">13 –14 septembre, de 9h00 à 18h00 les deux jours 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 . 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 »: 13 – class="dtend" title="2008-09-14T18:00:00">14 septembre, de 9h00 à 18h00 les deux jours duration La propriété duration décrit la durée (en temps) de l’événement. Dans mon exemple, deux jours : Un évènement de class="duration" title="P2D">deux jours 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. 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 . 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 : « 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 () pour l’événement : Oui c'est un billet rapide, mais marquez vos agendas : class="url summary">BarCamp Albuquerque 3 c'est ce week-end. Vous remarquerez que j’ai ajouté la propriété url à la propriété summary. Ceci tout simplement parce que le contenu embarqué par le é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 » : Oui c'est un billet rapide, mais marquez vos agendas : BarCamp Albuquerque 3 c'est ce week-end. 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 : Vous pourriez vous demander ce qu'est un class="category" rel="tag">BarCamp ? Souvenez-vous, rel-tag ne peut être uniquement utilisé que sur des liens (). location La propriété location décrit où aura lieu l’événement. class="location vcard"> href="http://www.chefwhite.com/cjw_cafe.php">CJW Cafe au 4801 Alameda Bd NE , Albuquerque, NM 87113 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 : class="description">Un évènement de deux jours 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. 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 : class="fn org url" href="http://www.chefwhite.com/cjw_cafe.php">CJW Cafe au class="adr"> class="street-address">4801 Alameda Blvd NE, class="locality">Albuquerque, class="region" title="New Mexico">NM class="postal-code">87113 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 : class="vevent"> Oui, c'est un billet rapide, mais à marquer dans vos calendries : class="url summary"> class="category">BarCamp Albuquerque 3 c'est ce week-end, class="dtstart" title="2008-09-13T09:00:00">13 – class="dtend" title="2008-09-14T18:00:00">14 septembre, de 9h00 à 18h00 class="duration" title="P2D">les deux jours. 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. class="location vcard"> CJW Cafe (sur 4801 Alameda Blvd NE , Albuquerque, NM 87113 ) sera notre hôte pour l'événement. 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 () : title="Télécharger le fichier .ics "> Ajoutez à votre calendrier 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
Emily Lewis : «Parvenir au Sémantique avec les Microformats, 3ème partie – hCard» xtof — Sat, 18 Oct 2008 11:47:15 +0000 J’ai démarré cette série d’articles en détaillant les microformats pour les relations fondées sur les liens en utilisant l’attribut rel dans la 1^èrePartie. Puis j’ai poursuivi dans la 2° Partie par une discussion sur l’extension de l’attribut rel avec les valeurs XFN pour connoter les relations sociales sur le web. XFN et les microformats fondés sur rel sont relativement simples, n’exigeant que l’ajout de l’attribut rel sur les liens () et la(es) bonne(s) valeurs pour fournir le contexte sémantique. Il est désormais temps de porter cette discussion sur les microformats à un niveau plus détaillé avec le microformat hCard, qui ajoute de la sémantique et de la structure au contenu web traitant des personnes, organisations, sociétés et lieux. (Mettez-vous à l’aise, c’est long.) Origines : vCard vCard est un standard pour les cartes de visite électroniques, qui sont le plus souvent attachées en pièces jointes aux courriers électroniques sous forme de fichiers avec l’extension « .vcf ». Tout comme les cartes de visite traditionnelles, les vCards contiennent de l’information sur le nom et le contact. La hCard a été présentée comme un format standard pour permettre aux auteurs du web d’inclure l’information vCard au sein de leurs pages web. hCard utilise une représentation 1:1 de la vCard. Ce qui veut dire que le contenu web marqué avec le format hCard peut être converti en vCards par les spiders et autres agrégateurs, et peut être utilisé dans n’importe quelle application ou service vCard. Personnes, Organisations, Sociétés & Lieux Le microformat hCard représente des personnes, organisations, sociétés et lieux — le plus souvent en termes d’information adresse/contact, y compris mais non limité à : Nom formaté/structuré Adresse postale/distribution Adresse e-mail Numéro(s) de téléphone Photographie Parmi toutes les informations qui peuvent être incluses dans hCard, la seule information obligatoire est le nom formaté. Tout le reste est optionnel. Et hCard, comme tous les microformats, utilise un marquage et des attributs existants pour spécifier cette information adresse/contact, et tout particulièrement différentes valeurs de classe, qui sont renvoyées sous des « propriétés » et « sous-propriétés. » Une Personne, à Savoir Moi L’une des premières implémentations hCard sur A Blog Not Limited est pour mon information personnelle de contact sur ma page About : class="vcard"> Emily Paige Lewis href="mailto:emily@ablognotlimited.com"> emily@ablognotlimited.com Albuquerque, NM 87106 USA A Blog Not Limited La première chose à considérer sur l’exemple ci-dessus est que tout le balisage et le contenu sont contenus dans une déclarée class="vcard". L’élément contenant pourrait être n’importe quoi ( , , , etc.), tant que cela reste de la syntaxe valide et de préférence sémantique. Ce qui est essentiel c’est class="vcard". « Mais le microformat s’appelle hCard … quel rapport avec la propriété vCard ? » me direz vous. Bon, ceci s’explique par la représentation 1:1 de la vCard. Toutes les propriétés spécifiées hCard (les valeurs class) sont fondées sur les noms des propriétés type vCard. Acceptez ça et avançons. Information d’Identité Personnelle En divisant l’exemple dans ses différentes propriétés, commençons par celles qui m’identifient personnellement, comme mon nom. Vous pouvez constater que mon information de nom est contenue dans : class="fn n"> Emily Paige Lewis La propriété fn indique que le contenu contenu à l’intérieur est une chaîne correspondant au nom de la personne, comme pourriez le voir sur une plaque nominative. Comme je l’évoquais précédemment, c’est une propriété obligatoire dans le microformat hCard. La propriété n indique que le contenu à l’intérieur contient les parties du nom d’une personne, comme le prénom, le deuxième prénom et les noms de famille. Bien que la propriété n soit requise par la spécification, elle peut être implicite (ce qui veut dire, non spécifiée), si le contenu regroupé par la propriété fn fait exactement deux mots. Le wiki Microformats explique en détail cette optimisation implicite. Il existe quelques autres propriétés d’identification que je pourrais inclure si j’étais encline à faire ainsi : class="nickname" indique le pseudo/nom de guerre d’une personne, et s’applique à un élément contenant le texte de ce pseudo. class="photo" indique une photo associée à une personne, et s’applique à un élément faisant référence à l’URL de la photo (via src). Cette propriété pourrait être aussi appliquée à un élément référençant l’URL de la photo via l’attribut data (bien que ce soit pour moi une option non-sémantique). class="bday" indique une date de naissance d’une personne, et s’applique à un élément contenant l’information de date. Aparté : Les Dates Mise à jour : 02 juin 2009 Le datetime design pattern est désormais déprécié en faveur du modèle-de-classe-value. Voir cet article en attendant la 8ème partie de cette série pour en savoir plus sur ce nouveau pattern. Je devrais mentionner que quand on arrive à l’information de date, celle-ci est souvent marquée avec de l’information à la fois lisible par les humains et par les machines. Ceci s’appelle le datetime design pattern. Sans rentrer trop dans les détails (parce que je traiterai cela en profondeur avec microformat hCalendar dans la 4^ème partie de cette série), voici un exemple sur la façon dont l’information de date est communément référencée dans les différents microformats : title="1974-09-04">4 Septembre 1974 >Remarquez que ce qui est contenu par le est de l’information-date-lisible-par-les-humains, alors que la valeur title est de l’information de date lisible–par–les–machines. L’utilisation de l’élément pour l’information de date (l’abbr design pattern), a cependant soulevé quelques problématiques d’accessibilité. Une fois de plus, je traiterai cela plus en détails dans la 4ème partie, mais ce qui a été proposé pour contourner ces problématiques est d’utiliser un élément avec une valeur title plutôt que . (Je traiterai aussi des problématiques d’accessibilité plus en détail en conclusion de cette série.) Sous-Propriétés Ainsi, pour revenir à l’exemple sur ma page About … Beaucoup de propriétés hCard ont des sous-propriétés pour fournir encore plus de contenu. Dans mon exemple, je marque le contenu dans avec des s référençant les sous-propriétés : class="given-name">Emily class="additional-name">Paige class="family-name">Lewis Mon premier prénom est indiqué par class="given-name". Mon second prénom est indiqué par class="additional-name". Mon nom de famille est indiqué par le class="family-name". Parmi ces trois sous-propriétés, given-name et family-name ne peuvent être seulement utilisées qu’une fois par vcard, alors que la sous-propriété additional-name peut être utilisée plusieurs fois. Et il existe deux sous-propriétés supplémentaires que j’aurais pu inclure : class="honorific-prefix" indique les préfixes du nom (par ex. M., Dr.), et qui s’applique à un élément contenant le texte de ce préfixe. class="honorific-suffix" indique les suffixes du nom (par ex. MD, PhD), et s’applique à un élément contenant le texte de ce suffixe. Comme additional-name, ces deux sous-propriétés peuvent aussi être utilisées plusieurs fois. E-mail & Téléphone La prochaine partie de l’exemple est mon adresse e-mail dans : ;class="email" href="mailto:emily@ablognotlimited.com"> emily@ablognotlimited.com Attribuer la propriété email à mon lien () indique que la valeur href est mon adresse e-mail. Le contenu regroupé par le pourrait être n’importe quoi. J’ai simplement choisi d’afficher la véritable valeur de mon adresse e-mail. La propriété email peut être utilisée plusieurs fois. Dans ces cas, la sous-propriété type peut être ajoutée pour savoir quelle adresse parmi les multiples e-mails est la préférée (« pref »): class="email" href="mailto:test1@test.com"> preferred email class="email" href="mailto:test2@test.com">alternate email Je pourrais aussi inclure une autre propriété, tel, qui indique un numéro de téléphone d’une personne (via la sous-propriété value). La propriété tel a une sous-propriété type pour indiquer le type de numéro (par exemple home, work, fax) : class="tel"> class="type">Work : class="value">555-123-4567 La sous-propriété type est complètement optionnelle. Si vous avez choisi de l’omettre, la valeur par défaut est « voice. » La propriété tel peut être utilisée plusieurs fois, comme le peut type. La sous-propriété type peut aussi indiquer « pref » pour afficher si c’est le numéro de téléphone préféré. class="tel"> class="type">Work (pref erred): 555-123-4567 class="tel"> class="type">Home : 555-789-0123 Pour finir, la sous-propriété value peut être implicite. Si un type est spécifié sans qu’aucune value ne soit spécifiée, alors tout autre propriété autre que type dans la propriété tel est considérée comme la value. Information d’Adresse La prochaine partie de l’exemple inclut mon adresse regroupée sous un : class="adr"> class="locality">Albuquerque, class="region" title="Nouveau Mexique">NM class="postal-code">87106 class="country-name" title="United States of America">USA La propriété adr indique les parties d’une adresse, que je décris par des s assignés aux différentes sous-propriétés de l’adresse : La ville est indiquée par class="locality". L’état est indiqué par class="region". Cette sous-propriété pourrait s’utiliser pour les provinces. Le code postal est indiqué par class="postal-code". Le pays est indiqué par class="country-name". Remarquez que pour mon country-name, j’ai utilisé l’élément pour une référence plus courte vers mon pays, avec le nom complet inclus dans le title. J’aurais pu tout aussi bien écrire le nom complet et contourner complètement l’e. Juste une question de préférence (même si j’encourage vivement à la concision sémantique). Pour des détails d’adresses encore plus précis, je pourrais aussi ajouter : class="street-address" pour mon adresse de rue class="extended-address" pour ajouter le numéro de mon appartement class="type" pour indiquer le type d’adresse (par ex. home, work) Aparté : address Mais attendez ! Qu’en-est-il de la sémantique ? Pourquoi ne pas utiliser l’élément comme le conteneur principal, plutôt qu’un ? En fait, jusqu’à ce que j’écrive cet article et fasse la recherche, j’ai découvert que j’utilisais de manière incorrecte depuis des années. J’avais toujours pensé que c’était littéralement pour les adresses physiques, comme dans cet exemple précis. J’avais tort. Selon le W3C, l’élément est : … employer l’élément ADDRESS pour fournir les informations de contact du document ou d’une partie essentielle de celui-ci, comme un formulaire. Compte tenu de cela, ce n’est tout simplement pas le bon élément à utiliser. Information sur le Site Web La dernière partie de mon exemple contient mon URL de blog dans : class="url"> A Blog Not Limited La propriété url indique que le lien () destination (href) se fait vers un site web associé à moi. Bien que je sois en train de référencer mon blog, ceci pourrait être aussi un lien vers mon portfolio design ou toute autre URL m’étant associée. Quelques trucs à remarquer concernant la dernière partie de l’exemple : En restant engagée avec les microformats fondés sur le rel, je me suis aussi assurée d’inclure rel="home me". Remarquez la facilité de combiner les microformats ? Le lien est contenu dans un , ce qui est tout simplement un paragraphe auquel j’ai déclaré une classe personnalisée pour supprimer l’affichage de l’information parce que je ne pense pas qu’il soit nécessaire de l’afficher dans cette situation spécifique. Sans tenir compte du fait que cela n’a rien à voir avec le microformat hCard. Produit Fini Après cette explication exhaustive du marquage, voici à quoi cela ressemble : Et du fait que hCard n’utilise que du XHTML standard, elle peut être stylisée de n’importe quelle façon comme il vous plaira. Si vous n’avez pas déjà compris, j’ai choisi une esthétique plutôt minimaliste, aussi j’en suis arrivée virtuellement à aucun autre stylisme que l’utilisation du class="nonVisual" pour supprimer l’affichage de quelque contenu. Mais pour voir un exemple de ce que vous pourriez produire, Chris Coyier a récemment posté une Carte de Visite Professionnelle en Microformats, qui utilise le marquage hCard avec une très belle CSS pour imiter une carte de visite traditionnelle imprimée. Les possibilités ne se limitent qu’à vos talents en CSS. Ajouter au Carnet d’Adresses ? Vous voyez dans mon exemple qu’immédiatement après mon contenu hCard, j’offre un lien vers « Ajouter à votre Carnet d’Adresses. » C’est tout simplement un lien vers le fichier vCard qui peut être téléchargé et ajouté à un programme de gestion de carnet d’adresses. Vous pouvez offrir facilement un lien direct vers le .vcf que vous créerez et maintiendrez sur votre serveur, ou vous pouvez tirer profit du Service Contacts de Technorati. (NDT : utilisez désormais le service de conversion de contacts h2vx) En utilisant la technologie h2vx de Technorati, vous faites simplement précéder l’URL de la page dépouillée de son préfixe http:// où votre microformats hCard réside avec http://h2vx.com/vcf/ http://feeds.technorati.com/contacts/, et puis utilisez l’URL résultante comme la valeur href pour votre lien (). Ce qui donne : href="http://h2vx.com/vcf/www.ablognotlimited.com/about/" title="Téléchargez la vCard" >Ajouter au Carnet d'Adresses Quand un utilisateur sélectionne ce lien, la vCard est créée dynamiquement et il peut alors la télécharger : Quelques Règles & Un Rappel Maintenant que j’en ai terminé avec mon premier exemple de hCard, il est nécessaire de faire remarquer quelques règles : Les noms de propriétés et de sous-propriétés sont sensibles à la casse. La « racine » vcard ne peut pas être mélangée avec n’importe laquelle de ses propriétés. Par conséquent, class="vcard fn" est invalide. Les propriétés ne peuvent pas être combinées avec les sous-propriétés. Par conséquent, class="tel value" est invalide. Pas si mal non ? Je veux dire, allez les microformats sont standards. Bien sûr il y a quelques règles. Et n’oubliez pas : Ce n’est pas intrinsèquement un problème de marquage quand on parle de microformats. Cela concerne les valeurs de classe et différents attributs de marquage — propriétés et sous-propriétés. Vous pouvez utiliser presque tous les éléments (X)HTML que vous voudrez et faire que les microformats soient encore valides si vous déclarez proprement les propriétés et sous-propriétés. Bien sûr, si vous vous souciez de comprendre la sémantique des microformats, vous devriez aussi comprendre le marquage sémantique. N’oublions Pas le Profil Tout comme je le mentionnais avec XFN, il est recommandé d’inclure le profil hCard dans le des pages web qui incluent le microformat : profile="http://www.w3.org/2006/03/hcard"> le W3C autorise plusieurs valeurs de profil, séparées par un espace blanc, ainsi vous pouvez avoir à la fois les profils pour hCard et XFN : profile="http://gmpg.org/xfn/11 http://www.w3.org/2006/03/hcard"> Mise à jour : J’ai récemment découvert qu’il existe un profil combiné pouvant être utilisé pour tous les microformats-non-draft, plutôt que de lister plusieurs profils dans le d’un document : Aussi si vous utilisez un microformat unique sur une page, vous pouvez utiliser ce profil combiné si ce microformat est non-draft. Néanmoins pour les microformats-draft (en projet), vous devez spécifier le profil pour ce microformat particulier. A cette heure, tous les microformats discutés dans cette série (à l’exception de rel-home) sont « non-draft ». A nouveau, comme je l’ai déjà abordé eu égard à XFN, je maintiens mon dans une inclusion globale, ainsi il y est fait référence sur l’ensemble du site A Blog Not Limited. Néanmoins, tel que cela se révèle, ceci est requis, parce que j’utilise le microformat hCard sur presque toutes les pages de mon site (dans le pied de page). Ce qui suit très joliment dans la prochaine partie de cet article … hCard en Langage Naturel Il y a de ça un moment, j’étais tombée sur un article génial du brillant Jeremy Keith, qui suggère d’utiliser hCard en langage naturel. En fait, il propose d’appliquer les propriétés et sous propriétés de hCard pour l’information de contact (par ex : nom, site web, email) qui apparaîtront dans le flux des phrases naturelles, à l’inverse du « découpage » de l’information de contact d’une personne comme montré dans mon premier exemple. Le concept est si simple et s’ouvre vraiment aux opportunités pour utiliser hCard. Aussi, ai-je décidé de l’utiliser dans mon pied de page sur A Blog Not Limited où j’ai quelques trucs me concernant : class="vcard"> title="En savoir plus à propos d'Emily">La Personne la plus Cool que Je Connaisse title="En savoir plus à propos d'Emily"> style="width:80px; height:80px;" class="photo" alt="Emily Lewis" /> Yeah ce serait moi : class="fn email" href="mailto:emily@ablognotlimited.com">Emily Lewis. Je suis class="title">web designer vit à class="adr"> class="locality">Albuquerque, class="region">New Mexico class="postal-codenonVisual">87106 class="country-name nonVisual" title="United States of America">USA , et suis une "standardista." Je suis spécialisée dans le (X)HTML sémantique codé à la main et CSS , concevoir des sites web accessibles, et l'écriture et optimisation du contenu web. class="url">A Blog Not Limited est mon blog personnel où je pontifie sur le design web, les standards du web, la sémantique et tout ce qui m'entiche. Les Différences Mis à part le fait que le contenu hCard dans ce second exemple soit « dans la ligne » avec du contenu non-hCard, il y a quelques légères différences dans les propriétés et sous-propriétés hCard utilisées : Je fais uniquement référence dans cet exemple à mon premier prénom et à mon nom de famille, aussi je n’utilise que class="fn". Souvenez-vous que la propriété n peut être implicite si le contenu fn fait exactement deux mots. J’inclus mon titre de job dans la description, aussi j’ajoute class="title", qui est l’une des propriétés fournissant de l’information à propos de l’affiliation professionnelle d’une personne. Cette propriété indique le titre de mon job. J’inclus une photo de moi-même, aussi j’ajoute class="photo" à . Néanmoins, ces différences avec le premier exemple n’ont rien à voir avec le fait que j’utilise la hCard en langage naturel. Ce n’étaient simplement que les valeurs appropriées à utiliser avec le contenu dans cet exemple spécifique.. Combiner hCard & XFN Comme je le mentionnais, ce concept de hCard en langage naturel fournit tellement plus de contextes dans lesquels la hCard peut être utilisée. Je l’ai déja appliqué à l’information à mon propos, mais je fais souvent référence à des amis et confrères dans mes articles … cela fait vraiment sens de marquer ces références avec hCard. Et peu importe si je marque déjà ces références avec les valeurs XFN. L’une des meilleures choses à propos des microformats est qu’ils peuvent être facilement combinés. Selon le contexte de la référence, j’utilise un marquage légèrement différent. Dans les situations où je fais référence à un article/billet (tel que la référence au-dessus à Jeremy Keith), j’utilise comme mon conteneur vcard : … le brillant rel="muse colleague" class="url fn" title="adactio.com">Jeremy Keith , qui suggère d'utiliser title="adactio : hCard en langage naturel">hCard en langage naturel. Et dans les situations où je fais simplement référence à la personne, j’utilise comme mon conteneur vcard : title="jenschwedler.com" class="url fn" rel="met colleague co-worker friend"> Jen Schwedler Pour finir, si je fais seulement référence à la personne par son prénom, j’utilise le conteneur du nom formaté avec le nom complet comme valeur pour title : class="url" rel="met colleague co-worker friend"> Ian Dans tous ces exemples, les différences de marquage reflètent simplement ma sémantique préférée. Les microformats hCard et XFN sont les mêmes : propriété fn pour le nom propriété url pour le site web valeurs rel appropriées. Et si j’avais de l’information supplémentaire à propos de ces types (comme un titre de job, un e-mail, etc.) je marquerais de la même façon ce contenu avec les propriétés/sous-propriétés appropriées. Organisations & Sociétés J’ai déjà rencontré des situations où je devais utiliser hCard pour décrire une société ou une organisation sur ce blog, et je voulais vraiment fournir un exemple sur la façon dont cela pourrait s’implémenter : class="vcard"> class="fn org">Big Ass Blow-Up Dolls class="logo" style="width:69px; height:69px;" alt="Big Ass Blow-Up Dolls" /> class="adr"> class="street-address"> 6969 Happiness Avenue, class="locality">Los Angeles, class="region" title="California">CA class="postal-code">69069 class="tel"> class="value">696-969-6969 class="email" href="mailto:goodtimes@babud.com">Envoyez-nous un e-mail class="url" href="http://www.babud.com/">Visitez Notre Site Web Comme vous pouvez le constater, la hCard pour les organisations/sociétés est en fait la même qu’elle l’est pour les individus. Les principales différences sont : En plus de la propriété fn pour le nom, le nom de l’organisation se voit aussi déclarer la propriété org. Et avec les sociétés/organisations, vous n’utilisez jamais la propriété n. Plutôt que photo pour l’, l’image associée est marquée avec la propriété logo. Lieux Ce que j’ai détaillé pour les sociétés et organisations serait la même approche pour les lieux. Vous référenceriez simplement le nom du lieu avec les propriétés fn org et appliqueriez toute l’information d’adresse comme je l’ai démontré au-dessus. Voici un exemple de hCard en langage naturel pour un lieu : class="vcard"> Durant ma visite à class="locality">Atlanta , class="region">GA , je prévois de jeter un oeil au class="fn org"> Centennial Olympic Park . Il y a quelques propriétés hCard spécifiques-aux-lieux qui sont particulièrement utiles pour les endroits (bien qu’elles ne soient pas uniquement limitées aux lieux) : La propriété geo spécifie la position globale en utilisant deux sous-propriétés, latitude et longitude. La sous-propriété latitude spécifie une valeur décimale qui indique la position verticale en relation avec l’équateur. La sous-propriété longitude spécifie une valeur décimale qui indique la position horizontale en relation avec le premier méridien. Parlons Avantages Ainsi, maintenant que j’ai traité plusieurs exemples de hCard, il est temps de passer aux avantages. Sémantique Vous saviez que ça arriverait. Je l’ai déjà dit et le répéterai encore une fois : L’usage des microformats ajoute de la structure et du sens au contenu web, le rendant à la fois lisible par les humains et les machines. Et tout cela avec des standards existants pour le marquage et les données. Ceci encourage aussi le concept plus large de standards du web qui profitent à tous. Partager l’Information de Contact En utilisant hCard pour marquer l’information de contact, vous rendez automatiquement possible le fait que cette information soit convertie en une vCard téléchargeable, qui peut alors être utilisée par les programmes tels que Outlook de Microsoft et le Carnet d’Adresses d’Apple. Vous pouvez utiliser le service de contacts de Technorati décrit précédemment, ou pouvez créer le vôtre et l’héberger sur votre propre serveur pour le téléchargement. En outre, il existe plusieurs modules/extensions de navigateurs qui exportent automatiquement l’information hCard en vCards : Firefox Operator 0.9.3 reconnaît le contenu hCard et offre aux utilisateurs une option pour exporter l’information sous une vCard pour utilisation dans leurs programmes préférés de gestion d’adresses : Vous pouvez aussi voir la liste des options dans la capture d’écran, Operator utilise l’information hCard pour chercher sur d’autres sites web, comme Google Maps : Tails Export 0.3.5 est une autre extension Firefox qui tire profit de l’information hCard pour l’export à l’intérieur d’autres programmes de carnet d’adresses : Safari Le plugin Safari Microformats est utilisé pour vous utilisateurs de Safari afin d’identifier les microformats hCard sur une page web et de la sauvegarder dans votre carnet d’adresses. Je ne suis pas une fervente utilisatrice de Safari, et l’installation de ce plug-in fût bien trop boîteuse pour moi … aussi je ne l’ai pas installé et ne peux pas vous fournir de capture d’écran. Bookmarklets Le concept derrière le plugin susmentionné a été implémenté dans un bookmarklet microformats indépendant du navigateur, et je peux confirmer que c’est vraiment très beau : Il existe aussi d’autres bookmarklets hCard. Chercher Le contenu web marqué avec des microformats a naturellement plus de sens. Ceci pourrait aider les moteurs de recherche à mieux évaluer le contenu que vous leur fournissez, et peut-être, augmenter votre classement dans les résultats des moteurs de recherche. Il n’y a jamais de garanties quand on arrive à la recherche, mais le contenu de qualité dans le contexte est toujours un bon démarrage. Au delà des résultats de recherche, bon nombre des moteurs de recherche sont en train d’implémenter hCard dans leurs propres applications et services : Google a ajouté les microformats à sa Google Maps. Technorati Microformats Search cherche les hCards et autres microformats, y compris hCalendar et hReview. Yahoo! Local marque ses résultats avec hCard, tout comme avec hCalendar et hReview. Réseaux Sociaux Les sites de réseaux sociaux utilisent les microformats hCard pour marquer les pages profils avec l’information de contact des utilisateurs, tout comme celles des « contacts/friends/followers » des utilisateurs : Twitter applique la hCard aux pages profil, tout comme celles des listes des « following » et « follower ». ClaimID applique la hCard sur les profils publics des utilisateurs. Last.fm applique la hCard sur les profils, qui comprend photo et url en plus de fn. Et ce pour n’en citer que quelques-uns. Regardez la liste complète des services qui utilisent hCard. Des Outils pour Vous Faciliter La Vie Je serais négligente si je ne vous faisais pas ressortir quelques outils utiles qui peuvent vous aider à implémenter bien plus facilement hCard que de coder à la main et vous obliger à vous souvenir de toutes les valeurs (bien que j‘apprécie) : hCard creator est un simple formulaire qui génère une hCard à partir de l’information proposée. Le validateur microformat hCard vous laisse proposer une URL avec un contenu hCard, et puis valide les propriétés et sous-propriétés. Il existe une anti-sèche hCard pour une référence rapide aux propriétés et sous-propriétés. Il y en a Tellement Plus Je suis entrée dans des détails vraiment spécifiques sur le microformat hCard. Mais il y en a bien plus encore que ce que j’ai pu mentionner. Je vous encourage vivement à prendre un peu de temps et lire toutes les propriétés et sous-propriétés disponibles du microformat hCard, tout comme à voir quelques-uns des exemples de hCard dans la jungle. A venir en 4ème Partie Bien que ce fût un article long (qui en dit beaucoup considérant ma tendance normale à la verbosité), j’espère que cela a été intéressant et au moins utile pour vous. Parvenir à la Sémantique Avec les Microformats, 4^ème Partie traitera du microformat hCalendar. 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 22 septembre dernier sur son blog personnel. Seul le lien original fait référence. Vous pouvez aider à raffiner cet article en me laissant un commentaire ou en éditant directement le code posé sur la page miroir de mon wiki-personnel. Merci d’avance. xtof
Emily Lewis : « Parvenir au Sémantique avec les Microformats, 2ème partie – XFN » xtof — Sun, 21 Sep 2008 06:06:31 +0000 Dans la première partie de cette série, j’ai expliqué différentes implémentations du microformat rel sur A Blog Not Limited. Tout en expliquant rel-me, j’ai rapidement abordé le microformat XFN. Il est maintenant temps de passer un peu plus de temps sur ce microformat très cool, qui fût en outre l’un des premiers. Mettre un Visage Humain sur les Liens Créé par le GMPG, le XHTML Friends Network est un moyen étonnamment simple et décentralisé de représenter les relations humaines en utilisant l’attribut rel dans les liens(). Le concept est identique à ce que je décrivais dans la Première Partie pour les relations fondées sur les liens : rel="me">Twitter Dans cet exemple, l’ajout du rel="me" indique que le lien de destination (href) fait référence à une page à mon propos (ou une page dont je suis responsable). Le microformat XFN prend cette référence « humaine » pour les relations fondées sur les liens bien plus profondément que ce que j’ai déjà discuté. Nous Sommes Tous Connectés XFN pousse le concept du rel-me au delà de l’identification personnelle de l’individu pour aller vers les relations sociales entretenues par une personne. Vous ajoutez simplement plusieurs valeurs qui décrivent ces relations à l’attribut rel d’un lien. Par exemple, je fais souvent référence dans mes articles de blog à mon ami et patron, Ian : rel="met colleague co-worker friend"> Ian Pitts Dans cet exemple, j’ai ajouté rel="met colleague co-worker friend" au lien faisant référence à son blog personnel. Les valeurs rel indiquent que : J’ai rencontré (met) Ian en personne. Ian est un confrère (colleague), ce qui veut dire que le considère comme un pair avec des intérêts et talents similaires. Ian est mon boss et par conséquent un collègue (co-worker). Je considère Ian comme mon ami (friend) (il a de la chance, non ?). Comment Sommes Nous Connectés La spécification XFN fournit des valeurs de relation qui sont volontairement simplifiées. Amitié/Familiarité Seule une valeur peut être utilisée dans cette liste : friend : varie selon les définitions personnelles. C’est fondamentalement le plus haut niveau d »intimité » dans la catégorie de familiarité. acquaintance : induit une familiarité mutuelle. contact : quelqu’un avec lequel vous avez l’information de contact. Physique met indique quelqu’un que vous avez rencontré en personne. Peut exister indépendamment de toutes les autres valeurs. Professionnel Une ou plusieurs de ces valeurs peuvent être utilisées : colleague : quelqu’un avec des intérêts et/ou compétences similaires aux vôtres ; un pair. co-worker : quelqu’un avec qui vous partagez un employeur. Géographique Seule une de ces valeurs peut être utilisée : co-resident : quelqu’un avec lequel vous partagez une adresse de rue. neighbor : une référence géographique plus étendue, généralement quelqu’un qui vit près de chez vous mais pas dans la même rue. Familial Seule une de ces valeurs peut être utilisée : child : quelqu’un dont vous êtes le parent, que ce soit biologique ou adoptif. parent : quelqu’un qui vous a enfanté, que ce soit biologique ou adoptif. sibling : quelqu’un avec qui vous partagez un parent, une fois de plus biologique ou adoptif, tout comme à travers le mariage. spouse : quelqu’un avec lequel(le) (ou sentez que vous êtes) marié(e), que ce soit légal ou non. kin : tout proche de vous, que ce soit par le sans, le mariage ou l’adoption. Romantique N’importe laquelle ou toutes ces valeurs peuvent être utilisées : muse : quelqu’un qui vous inspire. crush : quelqu’un vers lequel vous êtes attiré(e), mais dont les sentiments peuvent ne pas être réciproques ou même savoir que vous existez. date : quelqu’un avec qui vous sortez régulièrement. sweetheart : une personne avec laquelle vous êtes intime sur le plan émotionnel et/ou physiquement, et vers laquelle vous êtes engagé(e). Du fait de ma propre confusion quand j’ai commencé cette tentative, j’ai pressenti que cela pouvait valoir la peine d’expliquer la valeur muse. Même si elle existe dans la catégorie romantique, c’est parti d’une perspective comparative en relation avec le rationnel. L’inspiration n’est pas rationnelle, de ce fait elle est romantique. J’insère fréquemment des liens vers quelques-uns de mes héros de l’industrie (Jeffrey Zeldman, Eric Meyer et Jason Santa Maria, pour n’en nommer que quelques-uns). Et pour tous, j’insère rel="muse". En aucune façon, ceci n’indique une relation romantique. J’admire tout simplement (et profondément) leurs travaux et les suit souvent pour de l’inspiration. Et juste un aparté personnel : j’ai trouvé les descriptions de ces valeurs romantiques extrêmement drôles et amusantes. Identité Personnelle me indique un lien vers vous-même à un endroit différent (href). C’est l’unique « relation » qui existe d’elle-même et reste exclusive de toutes les autres valeurs de relation. J’espère que c’est évident, mais au cas où ce n’est pas considéré simplement que même si vous pressentez que vous êtes un ami de vous-même, déclarer la valeur friend est redondant. Tout comme met et toutes les autres. Vous n’avez tout simplement pas besoin d’elles et elles ne sont pas valides. Délibérément Simple = Efficace Même moi, en tant que personne très pointue sur le détail, je peux apprécier la simplicité et l’efficacité de ces valeurs. Plutôt que de débattre pour savoir si quelqu’un est, par exemple, un superviseur ou un subordonné, j’accepte simplement que co-worker soit une valeur plus large qui englobe les deux. Cela vaut la peine de mentionner qu’il n’existe pas d’ordre spécifique qui ait besoin d’être suivi quand vous utilisez ces valeurs. En outre, la réciprocité dans ces valeurs n’est pas obligatoire. Ainsi, si vous faites référence à une personne en tant que friend et qu’elle fait référence à vous en tant qu’acquaintance, ce n’est pas un problème (à moins que vous ne souffriez extrêmement d’un manque d’estime de vous-même et le preniez personnellement). Spécifier un Profil En plus de déclarer les valeurs rel sur les liens vers quiconque que vous connaissez, le GMPG recommande que vous laissiez aussi les navigateurs et moteurs de recherche savoir que vos pages supportent XFN en spécifiant le profil XFN dans l’en-tête des pages avec des liens de relation XFN. En ce qui me concerne, j’ai choisi de déclarer le profil de toutes mes pages par que mon est maintenu dans un fichier global include. Ceci me facilite la maintenance, en outre, au minimum le rel="me" apparaît sur toues mes pages (dans les liens du pied de page vers mes pages profil Flickr, Delicious, iLike et Twitter ) : profile="http://gmpg.org/xfn/11"> Dites-le au Monde Le GMPG recommande aussi de faire savoir aux gens que votre site est « XFN-friendly ». Ils fournissent même un petit marqueur que vous pouvez ajouter sur votre site : Personnellement, je ne suis pas très fan des boutons et badges. Je préfère une esthétique plus discrète. Mais je supporte vraiment l’effort, ainsi j’ai ajouté un lien XFN dans mon pied de page : title="XHTML Friends Network Friendly">XFN Faites que ce soit Plus Facile pour Vous Même si ajouter simplement un attribut et quelques valeurs aux hyperliens ne constitue qu’un tout petit effort, il existe quelques outils disponibles qui rendent le XFN plus facile à implémenter : Créateur XFN 1,1 est une application web qui crée des liens avec les valeurs XFN propres et est disponible en plusieurs langues. MT Blogroll 2.12 Manual est un plugin pour Movable Type qui vous permet de définir les relations XFN pour les liens dans la 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 balisage du contenant, tout comme les valeurs title pour les liens. WordPress Links Manager est configuré pour vous permettre de définir les relations XFN pour les liens de blogroll. WP Microformatted Blogroll 0.2 est un plugin WordPress qui produit des liens microformatés annotés sur votre blog. rel-lint est un bookmarklet JavaScript qui vérifie les valeurs XFN connues et marque celles qu’il ne reconnaît pas. Le Web Sémantique Je sais que je l’ai déjà dit encore et encore (et ce n’est pas près de se terminer) : la sémantique est l’un des bénéfices de base des microformats, et XFN n’y fait pas exception. L’usage ajoute de la structure et du sens au contenu, le rendant à la fois lisible par les humains – tout comme par les machines. Et même encore mieux, il le fait en utilisant des standards existants pour le marquage et les données. Brillant ! Les microformats nous emmènent vers un pas plus proche du Web Sémantique visionné par Tim Berners-Lee. Le Web Social Tout comme la sémantique seule me donne raison d’implémenter les microformats sur ce blog, je réalise que ce ne peut être suffisant pour certaines personnes. Pour ces personnes, je soupçonne que les aspects « sociaux » de XFN peuvent être plus importants. Recherche Sociale Rubhub est un moteur de recherche sociale où vous pouvez proposer votre site, et il est indexé et comparé à d’autres sites dans l’index rubhub pour identifier n’importe quelles relations sociales. Une fois indexé, vous pouvez voir les résultats sociaux de votre site, y compris les autres sites liés à votre identité (via rel="me") et les sites des personnes qui vous référencent (y compris comment elles vous référencent). Visualisations XFN Graph crée des diagrammes en étoile sur la manière dont les sites se relient les uns aux autres, fournissant une représentation visuelle des relations sociales entres les auteurs de site/blog. A partir de ça, vous pouvez voir comment les personnes se connectent aux autres et trouver de nouvelles personnes qui partagent des intérêts similaires aux vôtres. Connectivité En utilisant XFN, l’API Social Graph de Google facilite le fait de trouver des amis dans de nouveaux endroits sur le web. Son application de démo My Connections, par exemple, vous montre comment vous êtes connecté(e) à d’autres personnes. Voici un aperçu des résultats provenant de A Blog Not Limited » Listes d’Amis Il existe beaucoup de sites, particulièrement les sites de réseaux sociaux, qui supportent le marquage XFN sur les listes d’amis/contacts. Tant Twitter et LinkedIn, par exemple, ajoutent rel="contact" à leurs listes de liens des « suiveurs » et des contacts. Pour aller un cran plus loin, plusieurs sites publient des listes d’amis hCard+XFN, qui peuvent être utilisées pour importer/s’abonner à d’autres sites qui supportent hCard+XFN. (Je couvrirai le microformat hCard en détail dans la partie 3 de cette série.) Ceci pose les fondations pour permettre aux utilisateurs de modifier l’information de réseau social sur un site et faire que les autres sites soient automatiquement mis à jour. Consolidation d’Identité Comme je l’évoquais dans la Partie 1, XFN est essentiel pour la consolidation d’identité. Sites de Réseaux Sociaux Par exemple, beaucoup de sites de réseaux sociaux associent rel="me" aux liens vers les pages de profil, que ce soit Flickr, Twitter, LinkedIn et d’autres encore. Ainsi, là où n’importe quelle page réclame l’autre, l’identité divisée est consolidée. ClaimID Il existe aussi des services de consolidation d’identité qui utilisent XFN. claimID, par exemple, vous permet de régler manuellement un profil avec toutes vos identités en ligne consolidées sur une page, chacune d’entre elle pouvant être annoté avec rel="me". Voici un aperçu de mon profil claimID avec des liens qui englobent le microformat rel-me : Un avantage supplémentaire de régler un profil claimID est que cela vous offre une OpenID. OpenID est un système ouvert, décentralisé et libre pour l’identité digitale centrée sur l’utilisateur. Elle utilise les technologies web existantes pour transformer les identités digitales existantes (telles qu’un blog, un flux de photos, etc.) en un compte qui peut être utilisé sur des sites supportant les connexions OpenID. Ceci n’a bien sûr pas de rapport avec la discussion XFN, mais c’est vraiment cool. Plaxo Il existe aussi le Graphe Social Ouvert de Plaxo, qui comprent un crawler qui démarre par une URL que vous saisissez et cherche les liens rel="me". Il balaye ensuite ces liens, jusqu’à ce qu’il ne trouve plus de liens à suivre. Il cherche aussi les liens bidirectionnels pour établir une « déclaration vérifiée » que c’est bien la même personne dans les deux endroits (href). Voici un aperçu des résultats du crawler pour A Blog not limited : Le carnet d’adresses en ligne de Plaxo et le service de réseau social supporte aussi XFN en ajoutant automatiquement rel="me" à n’importe lesquels des sites personnels que vous ajoutez à votre profil. Chacun des liens « Emily on the Web » provenant de mon profil Plaxo a le microformat rel-me annoté : Même l’API Social Graph de Google comprend une application de démonstration, Site Connectivity, qui vous montre votre identité consolidée en listant les sites qu’elle sait de vous, tout comme ceux qu’elle pense pouvoir être de vous. Voici un aperçu des résultats que j’ai obtenus pour A Blog Not Limited : Un peu de Style Aussi abordé dans la Partie 1, vous pouvez utiliser les sélecteurs d’attribut CSS pour ne styliser que les liens comportant des valeurs spécifiques rel. Par exemple, mettons que vous vouliez tirer profit des icônes microformats XFN, vous utiliseriez des sélecteurs d’attribut pour déclarer : a[rel~="friend"]:before {content: url(xfn-friend.png);} Dans les navigateurs supportant la spécification CSS 2.1 (qui ne doivent pas être cette merde de navigateur IE6), ceci pourrait s’afficher comme suit : A venir en Partie 3 Ceci clôture mon billet sur XFN. Parvenir au Sémantique avec les Microformats, 3ème Partie traitera du microformat hCard. Restez branché … 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 17 septembre dernier sur son blog personnel. Seul le lien original fait référence. Vous pouvez m’aider à raffiner cet article en laissant un commentaire ou en éditant directement le code posé sur la page miroir de mon wiki-personnel. Merci d’avance. xtof

xtof » ressources

Intro au HTML5 : Structure

HTML5 : La Structure Principale

Hier

Mardi

Highlights of Qualifications

Technical Expertise

Web Design & Development

Experience & Accomplishments

Web Designer

class="fn n" id="emily-hcard-name">class="given-name">Emily class="additional-name">Paige class="family-name">Lewis

Propriété Optionnelle : summary

Highlights of Qualifications

Propriété Optionnelle : skill

Folie de Lien

Les Espaces de Tags Semblent Hors de Propos

Propriété Optionnelle : experience

Web Designer

Web Designer

class="summary">Web Design & Development Certification

class="entry-title">L'Accessiblité Web Est Importante

Attention : address Avec hCard

Sous-Propriété Requise : updated

Sous-propriété (optionnelle) : published

Datetime Design Pattern

Sous-Propriété Optionnelle : entry-summary

Sous-Propriété Optionnelle : entry-content

Optionnelle : rel-bookmark

Catégories en Combinant les Microformats

Exemple : Plusieurs Billets

class="entry-title">rel="bookmark">Web Accessibility Is Important

Propriété Optionnelle : `summary`

Propriété Optionnelle : `skill`

Propriété Optionnelle : `experience`

Attention : `address` Avec hCard

Sous-Propriété Requise : `updated`

Sous-propriété (optionnelle) : `published`

Sous-Propriété Optionnelle : `entry-summary`

Sous-Propriété Optionnelle : `entry-content`