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à…) 😀
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 😉
Bah…
a mon avis, y’a pas rop de souçi pour savoir ou est quand utiliser des lsites ou autre marquage.
en général, il suffit de se demander ce que l’on met en forme pour trouver la balise a utiliser….
Non ?
@luc > en tant que rédacteur, oui, il n’y a généralement pas de problème. En revanche, en tant qu’intégrateur html, on se pose souvent la question sur certains blocs qui se répètent dans la mise en page : est-ce qu’on les traite comme des blocs avec pour chacun une balise DIV ou alors est-ce qu’on les traite comme des listes.
ben, des éléments répétés, en générale se sont des listes non ?
liste d’actus… liste de rendez-vous… donc ? on utilise une liste non ?
dans tous les cas le html généré comporteras des divs
div class= »actu » > div class une_actu
qui peut se remplacer pa
ul class= »actu » > li class= »une_actu »
ni plus ni moins de html, mais l’illustration d’une liste.
après ce qu’il faut se demander c’est si effectivement ou non, on énumère une liste de quelque chose
@Luc : c’est parce que tu travailles avec une interface graphique.
La meilleure des démarches, à chaque fois que l’on implémente un contenu dans une page web, reste de se poser la question : de quelle nature est ce contenu que je vais implémenter ? nature qui sera alors traduite en HTML par sa balise adéquate.
Le balisage HTML n’est pas anodin, il donne la nature de l’information (et n’est donc pas d’ordre « sémantique » parce qu’il ne porte pas sur le sens des mots).
HTML a choisit une structure à plat et ce n’est pas pour rien.
Quel est votre but en utilisant une liste pour tout et n’importe quoi ? On me parle de structuration sémantique mais votre lecteur HTML il n’a pas besoin d’une balise de liste pour savoir qu’une suite de paragraphe c’est une liste de paragraphe.
Inversement, quand vous faites une liste, demandez vous ce que votre machine qui lit le HTML doit tirer comme information de la présence de votre liste. Si vous ne savez pas quelle information on peut bien en tirer, si cette information ne peut pas être devinée automatiquement par une machine (genre : il y a besoin du contexte), si vous ne savez pas à quoi ça peut bien servir à la machine d’en face, ou si vous ne savez même pas quelle information vous envoyez en mettant une liste … c’est probablement que vous ne devriez pas mettre de liste.
Une liste de lien, une énumération de courses à faire, une liste d’étapes sur une procédure, ok. Mais ne mettez pas une liste de tout et n’importe quoi. Faire votre texte sous forme de liste de paragraphe c’est faire n’importe quoi.
A mettre trop d’information n’importe où vous empêchez la machine de tirer une information utile là où la balise est vraiment nécessaire. Pire, vous allez spammer certains lecteurs non graphiques avec des informations inutiles.
En fait la règle est assez simple : si à l’écrit sur une feuille blanche vous auriez mis des puces ou des tirets pour séparer les paragraphes, ça va en liste. Si c’est une énumération que vous auriez séparé par des virgules ou points virgules, ça peut éventuellement aller en liste. Si ce n’est aucun de ces cas, ça ne devrait généralement pas aller en liste. Ca peut aussi se voir quand vous n’appliquez aucune feuille de style. Si vos puces vous semblent inutiles ou bizarres, c’est que votre liste n’a probablement pas lieu d’être.
@Eric > lol, je précise parfois que des morceaux d’humour sont restés collé au texte, là, apparemment c’était pas assez clair.
« Ca peut aussi se voir quand vous n’appliquez aucune feuille de style […] c’est que votre liste n’a probablement pas lieu d’être. »
Ok, l’humour pour les listes à la place des paragraphes n’était peut-être pas évident à saisir, mais pour le coup je pense avoir été assez clair là-dessus :
« 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. »
et la liste n’était pas d’abord un excellent remède à la « divite » ?
(le p dans le li, il fallait oser… C’est beau)
Bon bé je vais quand même pas répéter ce que j’ai déjà dit dans l’autre article… et puis concernant les listes, je ne suis pas un pro de « sémantiquement correct », mais à trop se prendre la tête, je ne suis pas sûr qu’on s’en rapproche…
Perso, je mets des listes quand j’ai besoin de listes et des paragraphes quand j’ai besoin de paragraphes, et ainsi de suite. Le HTML me semble assez simple au départ, j’ai pas trop envie de complexifier tout ça… Y a bien d’autres aspects beaucoup plus obscurs sur lesquels se focaliser non ?? Enfin, moi j’dis ça, mais en même temps j’dis rien !! 😉
@Nicolas > ah, enfin quelqu’un qui me comprend :)) En fait, c’est assez amusant de constater les mouvements de balancier dans le webdesign et l’intégration : des tableaux on est passé aux structures en div (5 légumes par jour, faut les placer dans la journée, là, c’est fait 😉 ) puis on essaie de promouvoir les listes pour enrichir le vocabulaire du webmaster… Pour arriver à un moment le mouvement fait un retour en arrière… J’espère qu’on repartira de l’avant avant de revenir aux tableaux :))
@Francis > Aïe, je sens que tu vas pas être content avec l’arrivée du html5, parce que question structuration du contenu, ça va être un peu plus rigoureux 😉 Mais bon, au final, il y aura aussi moins de questions à se poser, donc ça sera peut-être plus simple à assimiler.
@bruno > le pire c’est qu’on est déjà revenu aux tableaux avec le retour en force des newsletters html, ah fireworks mon amour…
Non, au contraire, je suis pour une plus grande structuration du contenu, mais de manière directe, sans bidouillage. Et de ce côté-là, html5, ce sera un grand plus, c’est clair !
Salut à tous,
@Nicolas : « Le retour en force des newsletters HTML », parce que cela avait disparu ? Je ne comprends pas. Mais il est vrai qu’intégrer du CSS dans des mails HTML ce n’est pas facile 😀
tient, ca me fais penser a un débat qu’on a eu au boulot la semaine dernière…
les newsletter c’est hazbeen non ?
rien ne vaut un contenu bien strcturé en Html pour être correctement intégrer dans un flux RSS pour être syndiquer joliement dans un autre site qui fera tranquillement votre promotion…
Désolé, je me suis battu il y a peu avec quelqu’un qui a effectivement mis des listes n’importe où, vraiment pas loin du « une liste de paragraphes », donc j’ai pris ça trop au pied de la lettre. Heureux de m’être trompé.
Yop globalement on est d’accord… j’adhère totalement au concept . Et je note qu’au plus proche du fond consiste justement à ne pas le « dépasser ». Je m’explique : je ne me demande pas si on accorde trop d’importance à nos descriptions mais si parfois certains n’en rajoute pas une couche supplémentaire qui, au lieu d’apporter en clarté/précision, alourdi encore inutilement. Exemple tiré par les cheveux mais j’ai pas mieux là à l’esprit : au lieu de dire simplement « voilà un beau cercle », dire « voilà ici un beau cercle rond ».
Je suis un grand adepte des listes (d’ailleurs j’imagine que c’est un chapitre qui a bien du te plaire dans un certain livre dont j’attends toujours ta critique ça) MAIS le premier qui me pond un roman imbriquant divers niveaux de li et d’ol pour les mots, les phrases et les paragraphes, je le… je sais pas ce que je lui fais mais il est sûr que je ne lirais pas son livre :p
PS : je suis déjà adepte de certaines pistes du draft d’HTML5. Je l’attends comme beaucoup avec pas mal d’impatience…
.Eric {
y a pas de mal, je reconnais aussi que j’ai un peu de mal à tout faire passer dans des formats de billets assez court comme celui-ci, mais je me soigne 😉
Ceci dit, il m’est déjà arrivé d’écrire des billets en mettant les paragraphes dans des listes (si, si) car au début j’avais commencé par faire une liste de liens que j’ai enrichis peu à peu au point de faire plusieurs paragraphes pour chaque élément de liste…
J’aurais pu supprimé les balises li, mais le résultat donnait quelque chose de tonique et d’engageant à lire, alors j’ai récidivé quelques fois 😉
}
.burninHat {
oui, je vois ce que tu veux dire par la redondance de certaines information dans le code, mais je pense pas en être là 😉 Quand je dis qu’il faut granularisé l’information, c’est en gardant à l’esprit qu’on structure du contenu, c’est à dire un document qui possède sa propre structure.
En fait, je n’ai pas été assez explicite, parce comme tout le monde l’a dit, il est facile de voir quand utiliser des listes dans un texte et quand ne pas le faire. En revanche, c’est parfois pas évident pour la structure de certaines mise en page qui pourraient être accomplies avec des blocs DIV ou avec des listes.
Dans les blogs, l’exemple le plus flagrand à mon sens, c’est le thème par défaut de wordpress, où les éléments de la sidebar ne sont qu’une seule et même liste pour les catégories, les pages, les flux, etc. Là où on aurait pu, faire des listes simples pour chaque fonctionnalité.
}
* {
Quelqu’un m’avait fait passer un lien vers un site anglais qui proposait une méthode pour faire des colonnes en utilisant des listes : le wrapper était une liste dans laquelle était imbriquée d’autres liste ordonnées pour les sidebars et les zones de contenu.
J’avais trouvé ça assez curieux, mais en affichant la page sans CSS, tout prenait un sens nouveau : la structure du document apparaissait plus clairement qu’avec des structure de colonnes en DIV.
Mais bon, c’est un peu extrême mais je pense que la curiosité doit l’emporter sur la méfiance… Quitte à reprendre nos habitudes ensuite 😉
}
Ah non t’en es pas là du tout (pas ce que je voulais dire non plus :p) mais parfois, sur certains sites, c’est l’impression qui se dégage…
Hello,
Plutôt d’accord avec Eric pour éviter autant que possible la listite aigüe. J’ai remarqué dans certaines applications la tendance à utiliser des listes à tout va, notamment dans la sidebar de WordPress (une horreur) ou du côté du forum Vanilla (argh). Pour ma part je limite autant que possible mon utilisation des listes au cas «normal» de la liste simple dans un contenu. Donc pas ou peu de LI censément «structurants» pour moi.
Il ne faut pas se voiler la face: la principale chose qui structure un document HTML, ce sont les titres. Si j’ai une structure Titre + Paragraphe, pour reprendre un flux d’actualités par exemple, c’est déjà structuré correctement. Si je bascule vers une structure de liste en mettant chaque coupe Titre + Paragraphe dans un LI, je ne fais que redoubler la structure, ce qui est passablement inutile.
Donc oui, j’utilise plutôt des DIV, qui sont des éléments HTML parfaitement valides et qui servent, dixit la spécifications HTML 4.01, de support aux styles et aux informations de langues (idem pour SPAN).
À vrai dire, je me méfie de la notion de sémantique en HTML, car elle est souvent mal appropriée. On peut parler de sémantique quand un balisage donné a un impact sur la compréhension du contenu ou son exploitation. Du coup, nos principaux outils pour appréhender la sémantique d’un document sont:
1. le rendu sans styles CSS;
2. le rendu dans les lecteurs d’écran;
3. les outils qui parsent le code HTML pour en retirer certaines informations marquées sémantiquement (microformats, moteurs de recherche éventuellement, etc.).
Je ne suis pas un expert du troisième point (ni du deuxième à vrai dire), mais quand j’ai l’impression de «sur-sémantiser» je vérifie autant que possible les points 1 et 2. À savoir: est-ce que je ne communiquerait pas une information peu claire, ou trompeuse, ou trop dense et donc pouvant gêner la compréhension ou la lecture linéaire du contenu?
Bruno, tu dis dans ton article: «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.» Pour ma part, je fais le constat inverse: quand je vois, en désactivant les CSS, des numéros ou puces de liste dont je n’arrive pas bien à cerner la portée (c’est à dire que je ne sais pas exactement quel contenu est à l’intérieur de tel ou tel item de liste), je trouve ça très gênant. J’imagine qu’avec un lecteur d’écran ça peut être gênant de la même manière, mais il faudrait demander à des utilisateurs réguliers.
Pour un exemple, on peut aller voir du côté du forum Vanilla et ses listes imbriquées. Exemple:
http://lussumo.com/community/discussion/7225/vanilla-114-released/
La chose dont je me méfie avec les listes, ce sont les listes imbriquées. L’utilisation un peu trop enthousiaste des listes amène assez vite à créer des listes imbriquées (cf. chez Vanilla, donc), et selon moi c’est du même ordre que les tableaux imbriqués: pas terrible côté accessibilité.
Voilà, ça n’est pas une question très importante et tu es toi-même conscient des limites à ne pas franchir (genre listes imbriquées sur trois ou quatre niveaux…), mais méfions nous de la réinvention systématique de la sémantique HTML. Nous sommes sans doute très frustrés par ce format de PRÉSENTATION qu’est HTML, et sa sémantique rachitique, pour chercher à tous prix à lui coller des listes de définitions abusives, à décrire chaque SUITE D’ÉLÉMENTS SEMBLABLES comme des listes UL et OL, etc. Admettons une fois pour toute que HTML 4.01 est un format de présentation avec un peu de sémantique (indications de langues, titres HN, BLOCKQUOTE et Q, et deux trois autres subtilités), et on se simplifiera largement la vie comme intégrateurs HTML/CSS. Si HTML 5 apporte de la sémantique en plus (SECTION et quelques autres), fort bien, mais ça n’est pas encore tout à fait le présent. 😉
My 2 cents. 🙂
@Florent > je comprends bien le point de vue selon lequel trop de liste tue les listes, et l’idée de structurer les paragraphes avec des listes est plus une boutade qu’autre chose 😉
Concernant la lisibilité des documents et des listes, c’est vrai que dans certains cas, la lisibilité en prend un coup s’il y a trop de liste utilisées à tord et à travers.
Merci pour tes 2 cents qui valent leur pesant d’or 🙂
je plussoie des deux mains (ça veut rien dire, je sais ! :p)
Puisque « le mot est une liste non ordonnée de lettres » j’ai envie de dire « rovba rupo ect tleicar » 😉
lol, je m’ai trompé sur ce coup-là, je corrige à l’occasion 😉
interessant exemple dans ta liste separée par des vigules. en Chine on a justement un signe de ponctuation specifique pour separer des elements d’une liste, la virgule d’Oxford
http://en.wikipedia.org/wiki/Serial_comma
A partir de la detection de celle ci, il est ainsi possible de mieux baliser le contenu textuel.
gabyu — je ne connaissais pas du tout cette virgule d’Oxford. Je mets toujours une virgule (plus rarement un point-virgule) à la fin de mes éléments de listes. J’ai arrêté l’usage du point-virgule suite à la lecture des livres de Philippe Djian (mais j’y reviens quand c’est nécessaire) 😉