Je passerai sur l’utilité de ce genre d’outils, que je trouve toute relative, pour me concentrer comme toujours sur le code HTML et sa structure.
Je code cela ainsi :
<ul><!--
--><li><small><a href="#">tag A</a></small></li><!--
--><li><small><small><a href="#">tag C</a></small></small></li><!--
--><li><big><a href="#">tag F</a></big></li><!--
--><li><small><a href="#">tag B</a></small></li><!--
--><li><a href="#">tag E</a></li><!--
--><li><big><big><a href="#">tag D</a></big></big></li><!--
--></ul>
J’entends déjà quelques commentaires sur l’utilisation de balises qui disparaitront sans doute avec HTML 5. Mais peu importe puisque je code actuellement en XHTML 1.0 Strict. Je ne vois pas de souci avec ça.
On me reproche souvent aussi d’utiliser des balises destinées à la présentation. Là encore, je ne suis pas d’accord. Pour moi <big> et <small> permettent de donner plus ou moins d’importance à un texte, pas à en changer sa taille visuellement (même si c’est l’effet graphique qui est obtenu).
Bref, ça me semble pratique, simple et sémantique. Pas vous ?
13 commentaires ↓
A y réfléchir je n’aurai rien contre em et strong (c’est même un des seuls cas où avoir de l’em et du strong peut avoir du sens et ne fait pas doublon) parce que ce que tu fais c’est bien appuyer certains termes et en appuyer encore plus d’autres.
Maintenant big et small ne me choquent pas plus que ça.
Par contre il n’y a pas de « pour moi X et Y veulent dire … ». La spec est assez claire pour big et small :
BIG: Renders text in a « large » font. SMALL: Renders text in a « small » font.
Ce n’est pas une question d’importance, mais uniquement une question de taille visuelle de caractère.
Arf… du coup, ça ne semble pas terrible par la séparation présentation/contenu.
Et d’un autre côté avec
<strong>et<em>, je ne vais pas pouvoir faire de surcharge comme je le fais.Un article très intéressant à ce sujet : Marking Up a Tag Cloud.
Il y a un moment, on s’était interrogés avec Nicolas Hoizey sur les tagclouds, et je serais assez pour utiliser effectivement
emetstrong, mais pas seulement, parce que la gradation n’est pas assez « précise ».À l’époque j’avais suggéré qu’on croise ça avec des tailles dans des
styles.Voilà un exemple de tagclouds sans styles, à part les tailles de polices (une « preuve de concept », quoi)
Ainsi :
emetstrong1emà2em.Un peu de javascript en plus pour permettre un tri (un peu sauvage, j’en conviens) soit par ordre alphabétique, soit par ordre de grandeur.
Pour info, l’élément small ne disparait pas en HTML5 mais change de sens et représente désormais des petits caractères (pour des commentaires secondaires et des mentions légales) :
L’exemple final de l’article de 24ways utilise une liste à puce ordonnée et des noms de classe sémantiques (de peu-populaire à extremement-populaire par exemple). Pour ne pas perdre d’information, le nombre d’occurence du tag est ajouté dans le HTML et masqué par la feuille de style.
Par contre je suis pas sûr de saisir s’il faut ajouter ou pas un
rel="tag"dans le nuage de tags pour y ajouter un microformat.Frank : il faut ajouter un
rel="tag"uniquement si ledit tag est en rapport avec la page en cours. J’ai vu ça bien implémenté il y a quelques jours, mais impossible de savoir où.L’utilisation de small et big m’a toujours semblée flou.
D’une part on a la possibilité de définir des niveaux de titres (1-6) et d’accentuer l’importance de parties de textes grâce à em et strong.
Le premier câs semble inutilisable dans ce contexte, et le deuxième nous limite à 3 possibilitées … strong, em, em + strong , modifiable en CSS, mais ça n’apporte aucun niveau supplémentaire visuellement sur un navigateur qui ne gère pas CSS.
Donc big et small semblent remplir une fonction … créer des niveaux « sémantiques » infinis dans le contexte donné peu importe le navigateur.
Imaginons que certains robots ou lecteurs d’écrans n’y apporte pas plus d’importances … On pourrait mélanger big/small + strong/em ?
Corrigez moi si je me trompe
Yves, je pense que tout bêtement
bigetsmallont été créés au moment de la grosse frénésie du HTML ‘visuel’.Le fait qu’on rationalise leur usage en dépréciant
biget en ajoutant à la spec quesmallveut dire small print, ce n’est pas une mauvaise idée, loin de là.Exemple presque pas hypothétique : chez orange, l’importance n’est pas donnée par la taille mais par la couleur et la graisse (orange gras contre gris sombre fin).
De même j’ai tendance à considérer comme important un truc d’une couleur plus marquée dans un pavé d’une couleur moins marquée, noir contre gris par exemple (je suppose qu’un théoricien cognitif nous expliquera un jour que ça procède du même phénomène que l’interprétation du gras).
Pareillement, dans une page manuscrite on repère les mots soulignés ou surlignés, et on n’a pas pour habitude d’écrire plus ou moins gros.
On pourrait assez facilement finir par en déduire qu’à part dans la seule convention très nouvelle du nuage de tag, donner une importance relative à des éléments en s’appuyant sur la taille des caractères n’est pas si fréquent que ça, et que donc le « sémantisme » de
big/smalltel qu’il existait jusque-là en HTML est assez oiseux et ne servait au final qu’à compenser les manques que les CSS ont depuis largement et bien plus précisément comblés.Tiens Vincent une question sur ton exemple de départ : pourquoi tu as mis des
<!-- -->entre chaque ligne ? Je n’avais jamais vu ça.Steph » Je pense que c’est pour éviter le bug de rendu IE qui rajoute des espaces blancs entre les li en plus des marges internes/externes quand ces li sont en display:inline (tout ceci purement de mémoire, corrige-moi ami lecteur).
Sinon, très intéressante remarque sur l’importance donnée au gras ou à la couleur par rapport à la taille, je n’avais jamais vu la chose sous cet angle. Du coup je ne sais plus trop quoi penser de ces balises honnies (small et big)… et vais probablement cesser de les utiliser. Je le faisais déjà peu, justement parce qu’elles me semblaient plus liées à l’impact visuel qu’à la sémantique, et constituaient donc une hérésie au dogme de la séparation du fond et de la forme.
Par ailleurs, mon avis sur les nuages de tags c’est que saynul dans l’ensemble !
STPo à tout bon !
Je cherche ma source (j’avais pompé l’idée sur le code d’un grand monsieur anglophone) mais je ne retombe plus dessus.
STPo : les nuages de tags ont leur utilité, faut pas exagérer. En particulier, la « classification à facettes » semblait un genre d’Eldorado inaccessible, et les nuages de tags sont une façon simple d’y arriver.
Cela dit, je ne m’y suis pas encore mis. Il y a au fond de moi quelque chose de trop cartésien sans doute qui veut une structure rigide-et-pyramidale et qui s’assortit mal de l’impression souvent bordélique que laisse le nuage de tags.
Petit retour sur l’exemple final de l’article de 24 ways, les mots-clés n’étant pas ordonnés par importance, l’utilisation de
<ol>est abusive, un simple<ul>suffirait.L’autre élément est qu’on cache via CSS des informations consultatives supplémentaires qu’on aurait pu mettre dans l’attribut
titledes liens.Laisser un commentaire