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 :
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
- infographiste@gmail.com
- bruno.bichet@gmail.com
- br1o@live.fr
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
- infographiste@gmail.com
- bruno.bichet@gmail.com
- br1o@live.fr
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 ?
Et la balise pour les mails ? 😀
toujours valable en xhtml en plus.
la balise que je voulais donner était : , mais forcément, WP l’a virée ^^ »
« address », avec les tags autour.
Dis donc, ton WordPress est cruel, surtout dans un blog ou on parle de html & co =)
@Darklg > bien tenté, oui, mais la balise address sert surtout pour contacter le concepteur ou webmaster d’un site ; elle ne sert donc pas — à priori — à envelopper toutes les adresses présentes dans une page web 😉
Y a de l’idée, continue comme ça, jeune padawan tu iras loin :))
Je suis personnellement très désagréablement surpris par cette proposition vue le site de Frédéric sur une base de balises « neutres » sans valeur d’information html sur le type de de contenu « balisé ». Seules les « class » ont une « valeur ».
Je me suis posé la même question que toi, mais au lieu d’une liste ordonnée je me suis plus penché sur l’usage d’une liste de définitions, car si on joue sur les mots, qu’est-ce qu’une « vcard » si ce n’est la définition d’une entité ou identité.
Tiens je vais me fendre de ma proposition, histoire de rigoler. 🙂
D’accord avec toi sur l’utilisation de listes imbriqués, mais pourquoi utiliser une liste ordonnée ? Il s’agit selon moi d’éléments non ordonné, et il serait donc plus juste d’utiliser un « ul » plutôt qu’un « ol » non ?
Je pense qu’il y a débat 😀
Ahhh les générateurs de hCard (et de hCalendar) et leur soupe à la balise ! Perso, je suis assez de ton avis si on cherche à coder une hCard complète. Par contre difficile d’échapper à la « spanite » lorsqu’on cherche à définir une identité « dans » un texte… Exemple :
<span class= »vcard » id= »hcard-bruno-bichet »><a href= »http://www.brunobichet.fr » class= »fn n url »>Bruno Bichet</a></span> nous parle des microformats.
(et encore, là je l’ai fait courte, sans les given-name, family-name, middle-name, etc.)
s’eut été mieux de remplacer par
Puis supprimer le premier niveau de LI
remplacer les par des
puis remplacer le par
et au final remplacer les de second niveau… par un unique dans lequel on mettra des comportant la classe adéquate….
Je ferais un billet sur mon blog ce soir pour proposer ma version… 😉
Putain de html qui n’est pas converti en text…. (sic)
@Aymeric > J’ai hésité un peu entre des listes imbriquées et une liste de définition (avec éventuellement des listes à l’intérieur). Je pense que les deux possibilités présentent un intérêt, même si à la réflexion, la liste de définition colle mieux à l’idée, en effet 😉
@Damien > J’ai commencé par une liste non ordonnée, puis je me suis rendu compte qu’en général on donne ce genre d’information dans un ordre bien précis, donc, voilà pourquoi la liste ordonnée, mais bon, ça reste du détail, et puis comme l’a fait remarqué Aymeric, la liste de définition est un bon candidat 🙂
@burning’ > Pas faux, mais en cherchant la petite bête, on peut obtenir le même résultat en mettant les listes en ligne via display: inline 😀 Peut-être un peu laborieux… quoique, la présence des balises span est moins répandue dans les CMS comme WordPress, alors que les listes sont utilisées partout (tiens cet arguments pourrait militer en faveur des listes ul ou ol vs les listes de définition :))
@luc > Dommage que WordPress nous prive de ton argumentation qui a l’air détaillée 😉 Je lirais ton billet avec intérêt.
à lire ici : http://lucmuller.free.fr/index.php?article=486-microformat-html-web-semantique-et-balisage
Ouaip alors là pour le coup des display:inline, je te laisse volontier t’amuser à générer les css qui vont avec quand les noms (référants à des hCard) sont perdus dans du contenu (et bonjour l’aspect sémantiquement du contenu au passage…) !!! 😀 Grand fou va ! 😀
Je sais pas si l’omniprésence des listes ordonnées (ou non) militent en leur faveur vs les listes de définitions ou en défaveur des codeurs et designers… (je te laisse méditer là-dessus, c’est super profond je trouve. ;))
Ouaip, j’allais aussi dans le sens des DL DT/DD.
un peu plus complexe ma proposition, car j’ajoute du OL entre temps et de la balise address…
mais bon, ma source est un peu complexe effectivement
@burnin’ > C’est vrai. De toutes façons je ne connais pas d’éditeurs qui proposent de pouvoir choisir la balise de son choix ET d’y ajouter une classe… WordPress commence propose tout juste en version 2.5 la possibilité d’ajouter une classe lors de l’import d’une image (ce qui est déjà pas pal).
L’idéal serait d’avoir un éditeur qui permettrait soit d’avoir accès à toutes les balises HTML, soit assurer comme le fait Scribefire en proposant d’envelopper une portion de texte par le nom canonique de la balise HTML que l’on veut. C’est simple et génial à la fois 😉 Manque plus que l’option des classes pour les CSS ou au moins les microformats les plus répandus et the cat’s in the bag!
Sinon, j’ai fait une petit mise à jour du billet pour intégrer une version en liste de définition suite à la suggestion d’Aymeric.
@Luc > Je viens de lire ton billet : effectivement, l’imbrication des DD OL est bien vu 😉
Ce qui me gène dans la mise à jours, c’est que pour un « dt » il y’a plusieurs « dd »
hors normalement
une définition de ce type c’est une relation 1-1 non ? un terme à une définition.
donc la définition est censé, je crois être entièrement incluse dans le dd.
c’est pour ca que j’utilise en plus des ol et des adresse pour distinguer les différentes parties de la définition du terme en cours.
pour ce qui est de l’intégration. il me semble clair que l’utilisateur final ne dois pas utiliser son RTE (rich text editor) pour créer sa vcard. ce doit être un plugin qui va permettre de récupérer les données et les insérer au bon endroit ce grâce à un développement spécifique.
P.S. j’aurais aucun mal a faire ça en TYPO3 par exemple.
@Luc > de mémoire, je croix que les specs autorisent plusieurs dt et/ou plusieurs dd. En tous cas, le site pompage.net l’utilise clairement dans les exemples donnés dans cet article consacré aux listes de définition 😉
Effectivement. pompage est d’ailleur une bonne référence.
seulement, si l’on suit l’exemple cité…
DT: Événement
DD: Date
DD: Description
DD: Lieu
DT: Liens internes
DD: Page d’accueil
DD: Section 1
DD: Section 2
DT: Liens externes
DD: Lien externe 1
DD: Lien externe 2
En l’occurence, chaques à chaque dd correspond une donnée propre. hors dans ton exemple, une définition (adresse par exemple) est divisé dans plusieurs balises dd.
on pourrai peut être imaginer quelques chose du type (je te laisse imaginer le balisage, car on sait qu’il ne passe pas…)
dt > « adresses »
dd1 > span class= »type » domicile : adresse du domicile en entière
dd2 > span class= »type » bureau : adresse du bureau en entière
avec dans la feuille de style : dd {list-style-type:numeric;}
de ce point de vu on conserve une cohérence dans la donnée définition, on a une hiérarchie au niveau visuel via la css.
seul question qui continuer a m’interroger un peu, comment est interpréter un dl dt/dd dans un lecteur d’écran.
en parlant d’accessibilité, toujours sur pompage, je note cette mention :
Les listes de définitions ne peuvent pas avoir l’apparence de données tabulaires, mais elles peuvent contenir des éléments d’accessibilité comme des descripteurs (labels) et des en-têtes (headers) pour mieux relier les informations.
je pense que ce genre d’ajouts label/header ajouterai encore en porté sémantique, cependant, la tout de suite, j’ai pas d’idée sur la manière de les intégrer.
@Luc > » hors dans ton exemple, une définition (adresse par exemple) est divisé dans plusieurs balises dd. »
Je ne vois pas ce qui pose problème : dans cet exemple, j’ai le terme « adresses » qui a plusieurs définition. Il faudrait voir si le format hCard permet de specifier l’email plus précisément, en utilisant l’attribut « type » par exemple.
Enfin j’en tiens une ! C’est à dire une hCard avec des caractères accentués!
J’essaye d’utiliser Technorati ou XV2 pour la transformation en vCard, et à chaque fois cela me sort des caractères ignobles dans Outlook (que la page source soit en UTF-8 ou en ISO-8859 ne change rien, que les caractères soient en clair, en è ou è non plus)
… je lâche ma question ici en espérant que des utilisateurs francophones déjà confrontés au problème ont une solution ?
Hum.. Je pense qu’il faut faire attention aux « li-vites », j’ai l’impression qu’à part les Hx et les p c’est une balise des plus utilisé, pourtant je ne vois pas spécialement pourquoi mettre des listes partout..
En plus l’intérêt de réfléchir sur le balisage sémantique de quelque chose qui rajoute de la sémantique n’a pas beaucoup d’intérêt. Les microformats fonctionnent par rapport aux classes, pas par rapport aux balises. C’est un peu en faire une couche de trop. La sémantique dans nos documents n’est déjà pas énormément utilisée, alors penser à la sémantique que l’on applique aux éléments que l’on met en avant sémantiquement je trouve que ça n’a pas vraiment de sens… (sans jeu de mot)
Je dirai que le sens à appliquer à une hcard dépend surtout du document. Et qu’il faut aussi éviter de faire de l’obésité sémantique, parce que ça vous fait perdre du temps et ça ne sert pas à grand chose au final…
Mmmm même si je suis loin d’adhérer à 100% au commentaire de Neovov je dois dire que c’est assez pertinent et mérite qu’on réfléchisse bien avant de baliser un document. C’est vrai qu’après avoir bien réfléchi à « est-ce que je décris bien mon contenu » il est intéressant de se demander « ouaip mais est-ce que je le décris pas un peu trop ». Sinon on risque d’avoir des documents qui finissent comme le « Bonheur des dames » de Zola, tellement précis que c’est impossible à lire sans choper la migraine (c’est un avis très personnel au sujet d’un ouvrage m’ayant
fait royalement chiertraumatisé durant ma scolarité :p@Marie-Aude Tu cherches quoi au juste ? Un outil pour récupérer proprement une hCard sur un site web ou un outil pour en générer ? Si c’est pour les récupérer, je te conseille de regarder du côté de l’extension « Operator » pour Firefox. Une vraie petite merveille pour les microformats !
.Neovov, .burninhat {
Arf, vaut mieux que je vous réponde sous la forme d’un billet, tiens ! 😀
}
.Marie-Aude {
J’aurais aimé t’aider, mais je n’ai pas Outlook pour faire des tests. D’après ce que j’ai compris de ta question, quand tu récupère des éléments en provenance du microformat hCard dans Outlook, les caractères accentués ne passent pas, j’ai bon ?
}
Voilà, si c’est la question et qu’une bonne âme peut appporter un élément de réponse à Marie-Aude, saicool 😉
@bruno bichet : « dans cet exemple, j’ai le terme “adresses” qui a plusieurs définition »
justement non, dans ton exemple adresse à UNE définition l’adresse complète, qui est explosé en plusieurs balise DD ce qui de mon point de vu, n’est pas correcte.
mais bon, je pinaille pour le plaisir de pinailler… d’ailleur, je pense que dans un cas pareil l’utilisation de la balise address me parait inévitable, mais bon…
Enfin, cette discussion aura eu au moins permis de mettre en exergue le fait que le html et par voie de conséquent, la sémantique et l’accéssibilité, sont loin d’être une science exacte.
Ca fait longtemps que je n’avais pas eu un débat aussi « constructif » sur un blog tient… je reprend confiance… :):)
JE rejoins un peu la vision de Neonov et Burnin’ Burnin’ 😉 sur le fait de finalement peut-être mettre un peu trop de détails et de finir avec un casque terrible !!
et cette phrase: « Et qu’il faut aussi éviter de faire de l’obésité sémantique, parce que ça vous fait perdre du temps et ça ne sert pas à grand chose au final… », c’est souvent une question que je me pose… Des fois je trouve que l’on passe un temps fou avec des trucs qui n’en valent peut-être pas la peine !! 😀
@Luc > ok, je vois ce que tu veux dire : depuis le début j’étais sur l’idée de l’adresse mail ^_ ^v
Mais bon, ça ne change finalement pas grand chose. Qu’est-ce qui définit une adresse postale ?
Lorsqu’on remplit un formulaire web ou papier pour inscrire son adresse, on remplit généralement plusieurs champs, donc, je suis convaincu que l’utilisation de plusieurs définitions de données est une utilisation correcte y compris pour les différents champs d’une adresse postale.
Je ne vois pas d’inconvénient, en revanche, à utiliser la balise address, même si au départ elle sert à contacter le webmaster du site. Mais là, je pinaille à mon tour 😉
C’est clair que l’intégration d’un document en html est loin, mais alors très loin d’être une science exacte : c’est dingue de voir à quel point un PSD peut être découpé puis intégré totalement différemment selon les intégrateurs 😉
@Francis > Je crois que je me suis mal exprimé : je ne dis pas qu’il faut mettre des listes partout : je cherche simplement à exploiter le maximum de balises html différentes en fonction du contexte.
Comment dire, c’est une manière d’élargir son vocabulaire. Après, selon son métier, on n’est pas forcément sensibles aux mêmes choses : quand je visite un site, 7 fois sur 10 je jette un oeil sur le code source ^_^
Un des autres avantages à utiliser des listes même dans les cas un peu limite, c’est la présence de plusieurs niveaux de balises qui permettent une stylisation plus fine en CSS : un background pour les balises ol, ul ou dl et un autre pour les li dt ou dd…
Et ça ne prends pas plus de temps : comme dit l’autre « ça ne coûte pas plus cher de bien baliser » 😉
« quand je visite un site, 7 fois sur 10 je jette un oeil sur le code source » … Effectivement… En même temps, ça me plairait bien de faire ça aussi, mais j’y passerais un temps fou !!! O_O Perso, je le fais uniquement quand le site a mis en place un truc qui m’intéresse et là je vais voir le code…
C’est vrai que les listes pour l’utilisation d’un balisage plus précis est intéressant. Mais donc à utiliser quand besoin est…
@Bruno
en fait ils « passent » mais se transforment, par exemple le è devient un Ĩ
… caractéristique d’un problème d’encodage, mais je ne vois pas où.
@Marie-Aude > Il faudrait que tu essaies avec autre chose qu’Outlook pour déterminer l’origine du problème.
Thunderbird est un logiciel de messagerie assez complet qui respectera peut-être l’encodage de ta vCard. Désolé de ne pas pouvoir t’apporter une aide plus conséquente 😉 A++