L’autre élément est qu’on cache via CSS des informations consultatives supplémentaires qu’on aurait pu mettre dans l’attribut title des liens.

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.

Je cherche ma source (j’avais pompé l’idée sur le code d’un grand monsieur anglophone) mais je ne retombe plus dessus.

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 !

Le fait qu’on rationalise leur usage en dépréciant big et en ajoutant à la spec que small veut 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/small tel 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.

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

The small element represents small print (part of a document often describing legal restrictions, such as copyrights or other disadvantages), or other side comments.

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.

À 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 :

1. on donne une information ‘grossière’ en trois tranches, normal, em et strong
2. on donne une information plus précise qui va, par exemple, aller de 1em à 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.