css 4 design » Sémantique http://css4design.com Le blog de l'intégrateur web Sun, 05 Feb 2012 18:10:56 +0000 en hourly 1 http://wordpress.org/?v=3.3.1 Quelques notes sur la balise h1 avec HTML5 http://css4design.com/quelques-notes-sur-la-balise-h1-avec-html5 http://css4design.com/quelques-notes-sur-la-balise-h1-avec-html5#comments Thu, 16 Dec 2010 13:19:29 +0000 Bruno Bichet http://css4design.com/?p=8356

La réponse courte à la question « Combien de balises h1 dans une page Web HTML5 ? » est : « Autant que nécessaire ! » En gros, chaque fois que vous avez une nouvelle section, vous  pouvez mettre un h1. D’une manière générale, h1 accompagnera article, aside, nav ou section avec brio ! (cf. Sectioning content). Allons voir ce que nous disent les spécifications HTM5 sur l’emploi des balises de titre h1 — h6, notamment les exemples concernant les niveaux de titre. Ils sont assez parlant bien que parfois déroutant lorsqu’on a l’habitude du balisage utilisé jusqu’à présent. Les éléments h1 — h6 représentent les niveaux d’en-têtes de leurs sections respectives. Quant à l’élément hgroup, il regroupe un ensemble d’en-têtes composé d’au moins deux niveaux de titre, comme un titre et son sous-titre ou un titre et le slogan associé (un bon candidat pour Logo et Motto, faute de mieux).

Quelques exemples avec H1

Les deux bouts de code qui suivent sont équivalent : 

<body>
    <h1>Let's call it a draw(ing surface)</h1>
    <h2>Diving in</h2>
    <h2>Simple shapes</h2>
    <h2>Canvas coordinates</h2>
    <h3>Canvas coordinates diagram</h3>
    <h2>Paths</h2>
</body>
<body>
    <h1>Let's call it a draw(ing surface)</h1>
    <section>
        <h1>Diving in</h1>
    </section>
    <section>
        <h1>Simple shapes</h1>
    </section>
    <section>
        <h1>Canvas coordinates</h1>
        <section>
            <h1>Canvas coordinates diagram</h1>
        </section>
    </section>
    <section>
        <h1>Paths</h1>
    </section>
</body>
La première forme est celle que l’on utilisera le plus souvent dans le cadre d’un CMS, puisque il est rare que l’on puisse saisir des balises section lors de la rédaction d’un article, même en passant par l’éditeur HTML puisqu’il supprime les balises exotiques. A moins qu’un plugin ne permette d’y remédier.

Dans un autre exemple, on trouve une utilisation des niveaux h1 suivis de h2 et h3 à l’intérieur des sections : 

<body>
    <h1>Apples</h1>
    <p>Apples are fruit.</p>
    <section>
        <h2>Taste</h2>
        <p>They taste lovely.</p>
        <section>
            <h3>Sweet</h3>
            <p>Red apples are sweeter than green ones.</p>
        </section>
    </section>
    <section>
        <h2>Color</h2>
        <p>Apples come in various colors.</p>
    </section>
</body>
Toutefois, le W3C recommande d’utiliser la forme suivante plus explicite et plus simple à maintenir si l’on doit modifier l’ordre des sections en cours de rédaction (ou lors de corrections plus tardives) : 
<body>
    <h1>Apples</h1>
    <p>Apples are fruit.</p>
    <section>
        <h1>Taste</h1>
        <p>They taste lovely.</p>
        <section>
            <h1>Sweet</h1>
            <p>Red apples are sweeter than green ones.</p>
        </section>
    </section>
    <section>
        <h1>Color</h1>
        <p>Apples come in various colors.</p>
    </section>
</body>
Si la première version semble mieux hiérarchisée, la deuxième est plus claire : un h1 gratuit pour chaque création de section explicite ! Et l’on peut continuer avec les balises h2, h3, etc. C’est la profondeur du document, l’imbrication des sections et des sous-sections qui définit la hiérarchie du document. Ce qui ne signifie pas que les balises h2  – h6 sont inutiles. Elle sont toujours indispensables pour structurer le message à l’intérieur des sections.

Pour l’application des styles CSS, en revanche, pas sûr que section section h1 {...} soit plus simple que h3 {...}. Voir à ce sujet HTML5 Titles Inception, la courageuse descente de Nicolas Hoizey dans les limbes pour styler les h1 selon leur profondeur.

Sémantique ou optimisation SEO ?

La question du nombre de fois où l’on peut utiliser la balise h1 dans un document présente deux facettes :

  1. Logique interne du document (Semantic). Un document est souvent identifié par un titre et les parties qui le composent par des sous-titres. Si un document peut ne posséder qu’un seul titre (à l’image des livres où le titre se trouve en couverture), il est possible d’utiliser un titre `h1` par `section`. On suppose alors que les sections forment des parties dissociables du tout. A cet égard, on peut se demander si une balise `article` n’est pas préférable dans la mesure où une partie indépendante peut bénéficier (en théorie) d’un flux RSS dédié.
  2. Le référencement au niveau de la page (In Page). Google accorde un poids supplémentaire (un petit poids, faut pas trop rêver non plus) aux mots-clés contenus dans les balises de titre `h1`, `h2` et `h3`. La tentation est grande de vouloir en utiliser un maximum dans une même page.

Est-il est possible de mixer ces deux approches en tentant le Jackpot de la beauté sémantique et du charme SEO ? Lorsqu’on regarde de près les ouvrages imprimés (livre ou magazine), on s’aperçoit que le titre ne se retrouve pas toujours uniquement sur la 1ère de couverture. Dans certains livres, le titre est parfois répété dans les feuillets intérieurs précédé et/ou suivi de quelques pages blanches. Dans certains magazines, le nom de la revue peut se retrouver sur toutes les pages avec le titre de la rubrique en regard.

Du coup, l’argument du titre unique pour l’ensemble du site Web — en comparaison logique avec le Livre (objet de référence dès qu’il s’agit de bon goût) — ne tient plus. CQFD. Reste la question du title présent dans les balises meta. D’un point de vue SEO, cette balise est fondamentale car elle fait office de titre dans les SERP’s (Résultats dans les pages de recherche). Il faut donc lui accorder un soin tout particulier. Elle doit être unique sur la page. Or, la plupart des CMS utilisent le titre de l’article pour garnir ce title, ce qui le fait apparaitre deux fois. Sans compter l’URL du billet qui reprend souvent ce même titre lors de la réécriture des URL (URL Rewriting).

Il est important de s’assurer que ce title n’est pas redondant. Le meilleur moyen d’y parvenir est de considérer qu’il représente le vrai titre de la page Web, indépendamment des niveaux de titres h1 présents (sans compter que la page n’est pas forcément synonyme de document) ou même du logo, qu’il s’agisse d’un texte ou d’une image. Le Web n’est pas totalement réductible aux pratiques de l’imprimé, fussent-elles de bon goût.

En matière de SEO, redondance rime avec décadence, du moins lorsque la répétition s’effectue sur des niveaux hiérarchiques d’égale importance.

Document vs Site Web

La plupart des exemples fournis par le W3C concernent des documents et pas des sites Web, et ce n’est pas un détail : de nombreuses ambiguïtés concernant le bon usage de la balise h1 viennent de là. Si l’on doit présenter le compte-rendu d’une réunion, le titre du document pourrait être l’objet du mail qui a servi pour inviter les participants.

Prenons par exemple le document suivant : 

<h1>«La Tête Dans l'Asso» accueille les nouveaux adhérents</h1>
<p>Cette année, l'association a recueillie une centaine de nouveaux membres [...]</p>
<h2>La réunion d'intégration</h2>
<p>blablabla [...]</p>
<h2>Le livret d'intégration</h2>
<p>blablabla [...]</p>
<h2>Partenaires</h2>
<ul>
    <li>La Tête dans l'Ecu</li>
    <li>La Tête allant vers... </li>
</ul>
Une fois que le document est balisé correctement, il reste à l’intégrer dans le site Web qui contient généralement des balises d’en-tête de différents niveaux avant et après la zone des articles. Pour simplifier, on peut utiliser le marquage suivant : 
<header>
    <hgroup>
        <h1>Mon logo qu'il est beau</h1>
        <h2>Mon Slogan qu'il est grand</h2>
    </hgroup>
    <p>Ma description étendue qu'elle est bien fichue [...]</p>
</header>
Sous réserve que le logo en question soit composé en HTML et signifie quelque chose. Pendant longtemps, ce blogzine avait pour titre «CSS & Webdesign», ce qui en faisait un titre efficace dans le sens où 1) l’expression était représentative du contenu et 2) signifiait quelque chose pour les moteurs de recherche. D’ailleurs, sans trop vouloir enfoncer le clou du SEO, si votre logo-titre n’est pas utile pour les moteurs de recherche (ex. css4design, logo en image), autant utiliser une balise div.

Pour intégrer notre document dans le site Web, nous allons l’envelopper avec une balise article. Puis, nous allons modifier le marquage du header pour supprimer la balise h1 bien que les spécifications HTML5 ne nous y oblige pas. L’idée est de garder la ou les balises h1 uniquement à l’intérieur de la balise article pour optimiser le SEO In Page. Nous en profiterons pour remplacer la description du site par un résumé de l’article qui servira de chapô : 

<header>
    <p>
        <span id="logo">Mon logo qu'il est beau </span>
        <span id="slogan">Mon Slogan qu'il est grand</span>
    <p>
    <p>Un résumé de l'article qui servira de chapô [...]</p>
</header>
<article>
    <h1>«La Tête Dans l'Asso» accueille les nouveaux adhérents</h1>
    <p>Cette année, l'association a recueillie une centaine de nouveaux membres [...]</p>
    <h2>La réunion d'intégration</h2>
    <p>blablabla [...]</p>
    <h2>Le livret d'intégration</h2>
    <p>blablabla [...]</p>
    <h2>Partenaires</h2>
    <ul>
        <li>La Tête dans l'Ecu</li>
        <li>La Tête allant vers... </li>
    </ul>
<article>
Pour continuer dans cette logique de donner la primeur au contenu principal de la page, le mieux est encore de le placer en premier dans le code. En effet, un des avantages du Web par rapport à l’imprimé, c’est que l’ordre d’affichage des éléments n’est pas forcément celui du code source. Ainsi, dans l’exemple, ci-dessus, on peut très bien placer le contenu de la balise article avant celui de header dans le code et inverser l’ordre d’affichage avec la propriété float ou position: absolute.

Adaptez la feuille de style aux documents, pas l’inverse !

Si les spécification du W3C autorisent — voire encouragent — l’utilisation de plusieurs balises h1 pour structurer le contenu à l’aide de section, il me semble important d’adapter le balisage HTML à la sémantique des documents. Vous trouvez ça bateau ? Pourtant je remarque que l’on a tendance à baliser les documents de manière à les adapter à la feuille de style que l’on a déjà, plutôt que d’adapter la feuille de style aux documents ! Cela passe par une analyse approfondie des documents existants, par la création d’une feuille de style CSS souple et par la capacité de remettre son travail en question selon la nature des documents à venir.

Linkographie

Articles sur le même sujet

flattr this!

]]> http://css4design.com/quelques-notes-sur-la-balise-h1-avec-html5/feed 35 Framework CSS — Sémantique, maquette dynamique et autres notes http://css4design.com/framework-css-semantique-maquette-dynamique-et-autres-notes http://css4design.com/framework-css-semantique-maquette-dynamique-et-autres-notes#comments Mon, 08 Mar 2010 07:12:41 +0000 Bruno Bichet http://css4design.com/?p=5540

Les frameworks CSS ont fait couler beaucoup de pixels : d’un côté, ils proposent une méthode à l’épreuve des balles pour placer les blocs sur sur la page en tenant compte des contraintes cross-browser ; de l’autre, ils ajoutent des classes CSS superflues dans le code HTML pour la présentation des contenus, ce qui n’est pas jugé «sémantique» par les farouches défenseurs d’une séparation entre le fond et la forme. Voilà en gros l’avantage principal et l’inconvénient majeur qu’on peut dégager si on met de côté le faux problème du poids de ces frameworks. Après avoir donné mon point de vue sur cette question de «sémantique» j’expliquerais comment l’ajout de classes liées à la présentation dans le HTML peut s’avérer très pratique à l’heure du web «sur-mesure».

Comment ça marche, un framework CSS ?

Le positionnement des blocs avec un framework CSS s’effectue grosso modo en attribuant une classe CSS pour spécifier les propriétés width et margin aux blocs avec une ou plusieurs techniques pour rétablir le flux HTML après les éléments possédant la propriété float.

Dans une grille en 16 colonnes, pour placer une image sur 4 colonnes et du texte sur les 12 restantes, on pourra utiliser le marquage HTML suivant (je vous fais grâce des CSS, le code HTML est assez explicite) : 

<div id="header" class="grid_16 clear">
    <div class="grid_4"><img src="/img/logo.png" /></div>
    <div class="grid_12 last">Mon texte sur 12 colonnes</div>
</div>
Pour beaucoup, les classes .col_16 et last (voire même .clear) sont une intrusion, que dis-je, une déclaration de guerre de la forme contre le fond. Pour tout dire, je suis assez partagé moi-même sur le sujet, mais je m’accroche… J’utilise souvent la partie «grille» des frameworks pour mettre en place la structure des pages car j’ai déjà l’habitude de concevoir le design d’un site avec un découpage en colonnes.

Attention, pas forcément du tout fait en 950px ou 960px mais en déterminant le «pas» de la grille selon mes besoins. Je laisse ensuite  les fastidieux calculs à un générateur de grille, qu’il s’agisse de boks pour Blueprint ou encore de 960 Layout System pour 960.gs.

Un peu (ou pas) de sémantique

Les classes .span-4 ou .grid_4 ne sont pas sémantiques dans le sens où — pour certains — elles véhiculent une notion d’apparence et non pas d’utilité, de sens. Ainsi, une classe .warning est préférable à une classe .rouge même si la couleur de .warning est rouge ; si on change d’avis, on aura l’air fin avec notre classe .rouge affichant du texte orange. L’idée, c’est d’être à la fois très précis et suffisamment générique pour s’adapter à toutes les situations.

Pour revenir aux classes spécifiant la largeur des colonnes, j’ai toujours pensé qu’elles apportaient du sens, un peu à l’image de la presse quotidienne où l’on met un titre sur 8 colonnes, signifiant ainsi son importance par rapport aux autres contenus (à supposer que la maquette comporte un maximum de 8 colonnes).

Le côté sémantique de la chose est surtout à mettre en regard des contenus à maquetter : s’ils n’ont pas de sens en eux-mêmes, toute la sémantique du monde n’y pourra rien changer :D

Pour finir avec cette question de sémantique, il reste la possibilité de renommer les classes .span-x ou .grid_x. En fonction de votre projet, vous pourrez utiliser des termes plus en accord avec vos contenus comme .a-la-une pour .span-16, .breves pour .span-4 ou encore .entrefilet pour .span-2, etc. On peut donc considérer que des contenus auxquels on applique un .span-16 sont plus importants que ceux auxquels ont attribut la classe .span-4 et ainsi de suite.

Comme j’ai déjà eu l’occasion de le dire dans Framework CSS sémantique ? Comment je vois les choses (et au risque de me répéter) :

[...] la suite des .span-x peut se comprendre comme l’importance accordées à chaque bloc : du moins important (.span-1) au plus important (.span-24), à l’image de la presse écrite où un article surmonté d’un titre en «8 colonnes à Une» mérite plus d’attention qu’un entrefilet sur 2 colonnes.

Les avantages des frameworks CSS

Standardiser les méthodes de travail

Quand plusieurs personnes interviennent sur le code HTML pour placer ou déplacer des éléments (ex. supprimer ou ajouter une sidebar, un bloc de contenu, etc.) il vaut mieux avoir un jeu de classes CSS (issus d’un framework ou non, d’ailleurs) pour éviter que chaque intervenant bidouille le fichier CSS avec sa «méthode» : certains sont adeptes des position: absolute, d’autres raffolent des float: left, d’autres des table, etc. Avec des classes standardisées comme span-x, last et les clearfix qui vont avec, tout devient plus simple et cohérent.

Des maquettes dynamiques côté serveur ou client grâce aux grilles

Autre argument qui milite en faveur de la mise en place d’une grille avec un framework, c’est qu’en travaillant de cette manière, il devient possible de modifier dynamiquement la mise en page côté serveur avec PHP ou côté client avec Javascript.

Pour distribuer votre contenu sur 4 colonnes au lieu de 8, il suffira de modifier tout ou partie du nom de la classe utilisée (le «4» de col_4 par «8», par exemple) sans être obligé d’intervenir sur la feuille de style ou d’en charger une autre à la volée.

Frameworks PHP, Javascript et pourquoi pas CSS ?

Les critiques concernant les frameworks CSS sont souvent les mêmes que celles qui ont été faites contre les frameworks PHP ou Javascript avant que leur utilisation se généralise. Pour illustrer mon propos, voici un extrait de l’intervention de Didier Galland sur WebDevFr à propos de l’industrialisation de l’intégration web :

On a tenu exactement le même discours à propos de PHP, puis à propos de javascript. Les frameworks dans ces deux domaines ont largement prouvé qu’ils permettaient des améliorations. Je ne vois pas pourquoi l’intégration (css/html + javascript) ne pourrait pas bénéficier des mêmes améliorations. On a le droit d’utiliser son framework personnel dans son coin, mais pour le bien de mon agence, je ne peux pas bloquer mes futures évolutions (en personne ou en techniques) à cause de cette attitude, j’aurais donc forcément tendance à privilégier un professionnel au courant de ces techniques dans mes recrutements ou mes contracteurs freelances.

Aller au bout de la logique du reset CSS

Tout le monde connait le reset CSS d’Eric Meyer que l’on trouve dans de nombreux framework. Quand on y réfléchit cinq minutes, la suite logique de ce reset, c’est le frameworks. Il faut bien voir que la plupart d’entre eux ne sont pas spécialement très lourds et quand on fait le compte des déclarations redondantes qui se trouvent dans une feuille de style un peu touffue (parce qu’évidement, si votre projet tient en 20 lignes de CSS, c’est peut-être pas la peine de se poser la question), on se rend compte que les frameworks ne sont pas si gourmands.

Remplacer les styles par défaut des navigateurs

J’ai toujours trouvé que les styles par défaut appliqués par les navigateurs manquait d’originalité et de peps. Il suffit de mettre un soupçon de Boilerplate ou de Typogridfy pour que de très banal, la mise en page par défaut prenne un coup de jeune et de modernité !

Comment déterminer le «pas de la grille»

Un argument récurrent qui va à l’encontre de l’utilisation des grilles concerne la partie conception graphique. Les grilles entraveraient la créativité. Pourquoi pas. Mais je mets au défi quiconque de proposer un design de site web qui ne rentrerait pas dans une grille. Une grille n’est pas forcément synonyme de 12, 16 ou 24 colonnes. Il peut s’agir de 2, 4, 6 ou 8 colonnes et pourquoi pas d’un nombre impair de colonnes comme 1 colonne (un peu le degré zéro de la grille, mais bon…), 3 ou 5 colonnes pour bénéficier d’une asymétrie créative ? Tout est possible.

Pour aller au plus simple, si l’on veut un site avec un bloc de contenu et une barre latérale, on pourra diviser la page en 3 parties pour obtenir les ratios 2/3 pour le contenu principal et 1/3 pour la sidebar ou en 4 parties, soit 3/4 pour le contenu principal et 1/4 pour la barre latérale. On pourra se baser sur les proportions 1/3 ou 1/4 pour la largeur des images accompagnant les textes.

Ensuite, rien n’empêche de diviser chaque colonne en plusieurs parties pour granulariser l’information selon les besoins : affichage de miniatures, etc. Celà permet d’obtenir une mise en page très simple tout en bénéficiant d’une système de grille souple et efficace.

Quelques liens à propos des frameworks et des reset CSS

Pas de conclusion hâtive !

Je pense que j’aurais l’occasion de revenir sur ces questions (oui encore) notamment sur la partie grille et créativité qui semble passionner beaucoup de monde à juste titre. N’hésitez pas à partager vos expériences en la matière. A bientôt !

Articles sur le même sujet

flattr this!

]]> http://css4design.com/framework-css-semantique-maquette-dynamique-et-autres-notes/feed 8 Granularisation du balisage HTML : parce que nos documents le valent bien… http://css4design.com/granularisation-du-balisage-html-parce-que-nos-documents-le-valent-bien http://css4design.com/granularisation-du-balisage-html-parce-que-nos-documents-le-valent-bien#comments Wed, 30 Apr 2008 07:51:41 +0000 Bruno Bichet http://www.css4design.com/?p=313

Suite à mon dernier billet sur les différentes manières d’aborder le balisage HTML d’une hCard, Neovov et burningHat ont soulevé la question de la sur-sémantisation du code d’une manière générale et de la sur-utilisation des listes en particulier. Neovov, par exemple, ne voit pas pourquoi on devrait mettre des listes partout. burninHat quant à lui, se demande si l’on ne n’accorde pas trop d’importance à la description de notre code HTML… Magneto !

Trop de listes tue les listes ?

Il n’y a jamais trop de listes, car tout est une liste :

  • le mot est une liste ordonnée de lettres,
  • la phrase est une liste ordonnée de mots,
  • le paragraphe est une liste ordonnée de phrases,
  • le texte est une liste ordonnée de paragraphes.

Dans ces conditions, on peut même se demander pourquoi utiliser des balises p pour les paragraphes au lieu d’une bonne vieille balise li… Et oui, il est possible de faire des p dans le li (ok, elle était facile, celle-là…) :D

Plus sérieusement, un des reproches que l’on fait souvent au HTML, c’est son manque de balises pour décrire les contenus. Alors ne boudons pas notre plaisir et profitons pleinement de nos 3 sortes de listes :)

Des descriptions à la Zola ?

La question que je me pose toujours quand je suis face à un document à intégrer htmlement parlant, c’est : à quoi celà devrait-il (va-t-il) ressembler en l’absence de feuille de style ou plus précisément : comment faire pour que la forme du document soit le plus proche possible du fond, sans CSS.

Je me rends compte que l’utilisation des listes à chaque fois que celà est possible améliore énormément la lisibilité des documents en donnant un aperçu de leur structure dès le premier coup d’oeil.

Reçu HTML 5 sur 7 ;)

Je suis convaincu que la granularité du balisage HTML doit être la plus fine et la plus précise possible. A cet égard, les travaux sur le HTML5 vont dans ce sens avec l’arrivée prochaine des balises relatives au découpage des documents comme section, nav, article, aside, header, footer ou encore la présence de l’élément dialog pour regrouper certains type de contenus. Cet balise dialog qui s’ajoute d’ailleurs aux éléments permettant de faire … des listes.

Ainsi, même si l’on pouvait utiliser les listes de définition pour mettre en forme des dialogues, le HTML 5 pousse le découpage un cran au-dessus. Une des raisons qui milite selon moi pour cette granularisation, c’est l’accessibillité des documents pour les lecteurs vocaux qui pourront moduler l’intonation en fonction des différents type de balise HTML.

Note : les plus observateurs d’entre vous auront peut-être remarqué que j’aurais pu créer une liste non-ordonnée dans l’avant-dernier paragraphe avec l’énumération qui commence par section, nav, etc. Je n’ai pas opté pour une liste, car le flux naturel de lecture risque d’être perturbé par un découpage trop systématique ;)

Articles sur le même sujet

flattr this!

]]> http://css4design.com/granularisation-du-balisage-html-parce-que-nos-documents-le-valent-bien/feed 25 Proposition de balisage HTML sémantique du microformat hCard http://css4design.com/proposition-de-balisage-html-semantique-du-microformat-hcard http://css4design.com/proposition-de-balisage-html-semantique-du-microformat-hcard#comments Tue, 29 Apr 2008 09:57:51 +0000 Bruno Bichet http://www.css4design.com/?p=312

En lisant ce billet de Frédéric de Villamil sur le compte rendu du troisième WASP café France dans lequel il présente un exemple de structuration du microformat hCard, je n’ai pu m’empêcher d’ajouter mon grain de sel pour remplacer la divite et la spanite par une structure à base de listes imbriquées que je trouve comment dire… plus sémantique…

En effet, dans leur précipitation à mettre en avant les attributs des microformats, les promoteurs du « web sémantique » en oublient souvent de travailler le code HTML qui se trouve autour. Bien que les exemples donnés généralement soient destinés à être personnalisés, force est de constater que les exemples sont souvent repris tels quels. Save the markup, save the web? Maybe ;-)

L’exemple hCard fournit par Frédéric

D’après l’exemple donné dans la documentation officielle : 

<div class="vcard">
  <a class="fn n url" href="http://fredericdevillamil.com">
    Frédéric de Villamil
  </a>
  <div class="adr">
      <span class="type">Domicile</span>:
      <div class="street-address">12 rue Danton</div>
      <span class="postal-code">94270</span>
      <span class="locality">Le Kremlin-Bicêtre</span>,
      <div class="country-name">France</div>
  </div>
  <div class="tel">
      <span class="type">Mobile</span> +33-6-62-1337
  </div>
  <div>Email:
      <span class="email">frederic@de-villamil.com</span>
  </div>
</div>

Ma proposition de balisage pour le format hCard

J’ai ajouté quelques attributs pour enrichir un peu l’ensemble : 

<ol class="vcard">
  <li>
      <h4>Identités</h4>
      <ul>
          <li class="fn n url">
            <a href="http://www.brunobichet.fr">
              Bruno Bichet
            </a>
          </li>
          <li class="fn nickname url">
            <a href="http://www.css4design.com">
              br1o
            </a>
          </li>
          <li class="photo url">
            <a href="http://www.css4design.com/identite_100x100.png">
              Tu veux ma photo ?
            </a>
          </li>
          <li class="note">
            Intégrateur web, blogdesigner et formateur
          </li>
      </ul>
  </li>
  <li>
      <h4 class="type">Adresse</h4>
      <ul class="adr">
          <li class="street-address">1, rue de l'intégration HTML</li>
          <li class="postal-code">69007</li>
          <li class="locality">Lyon sur CSS</li>
          <li class="country-name">France</li>
      </ul>
  </li>
  <li>
      <h4>Téléphones</h4>
      <ul class="tel">
          <li class="type">Mobile : +33 6 00 00 00 00</li>
          <li class="type">Fixe : +33 4 00 00 00 00</li>
      </ul>
  </li>
  <li>
      <h4>Emails</h4>
      <ul>
          <li class="email">infographiste@gmail.com</li>
          <li class="email">bruno.bichet@gmail.com</li>
          <li class="email">br1o@live.fr</li>
      </ul>
  </li>
</ol>
Ce qui donne la mise en forme suivante selon la feuille de style employée globalement sur le blog :

  1. Identités

  2. Adresse

    • 1, rue de l’intégration HTML
    • 69007
    • Lyon sur CSS
    • France

  3. Téléphones

    • Mobile : +33 6 00 00 00 00
    • Fixe : +33 4 00 00 00 00

  4. Emails

La même hCard en liste de définition

Mise-à-jour : Sur une remarque judicieuse d’Aymeric dans ce commentaire, voici la version « liste de définition ». Cette version semble effectivement plus adaptée : plus légère et le code est plus clair. Que du bon air, heu… du bonheur :) 

<dl class="vcard">
  <dt>Identités</dt>
  <dd class="fn n url"><a href="http://www.brunobichet.fr">Bruno Bichet</a></dd>
  <dd class="fn nickname url"><a href="http://www.css4design.com">br1o</a></dd>
  <dd class="photo url"><a href="http://www.css4design.com/identite_100x100.png">Tu veux ma photo ?</a></dd>
  <dd class="note">Intégrateur web, blogdesigner et formateur</dd>



<dt class="type">Adresse</dt>
  <dd class="adr street-address">1, rue de l'intégration HTML</dd>
  <dd class="adr postal-code">69007</dd>
  <dd class="adr locality">Lyon sur CSS</dd>
  <dd class="adr country-name">France</dd>



<dt>Téléphones</dt>
  <dd class="tel type">Mobile : +33 6 00 00 00 00</dd>
  <dd class="tel type">Fixe : +33 4 00 00 00 00</dd>



<dt>Emails</dt>
  <dd class="email">infographiste@gmail.com</dd>
  <dd class="email">bruno.bichet@gmail.com</dd>
  <dd class="email">br1o@live.fr</dd>
</dl>
Ce qui nous donne le résultat brut de décoffrage suivant. (A noter que cette version oblige à ajouter certaine classes comme adr ou tel à chaque entrée de définition alors que dans la version précédente, nous avions la liste imbriquée ul pour englober l’ensemble) :

Identités
Bruno Bichet
br1o
Tu veux ma photo ?
Intégrateur web, blogdesigner et formateur
Adresse
1, rue de l’intégration HTML
69007
Lyon sur CSS
France
Téléphones
Mobile : +33 6 00 00 00 00
Fixe : +33 4 00 00 00 00
Emails

Pour conclure

Je ne suis pas un expert en microformats et je me pose pas mal de questions. Dans mon exemple, vaut-il mieux utiliser la classe email sur chaque élément de liste li ou une seule fois dans la balise ul ? Si vous avez des suggestions concernant le placement des attributs des microformats dans le balisage HTML, n’hésitez pas à participer ;)

PS : connaissez-vous le site des microformateurs pour suivre l’actualité des microformats en français ?

Articles sur le même sujet

flattr this!

]]> http://css4design.com/proposition-de-balisage-html-semantique-du-microformat-hcard/feed 33