Liste ou <br /> pour un menu ? [Résolu]

Bonjour, petite question pour un menu vertical.
Dans la plus part des cas on choisi ce code :

<ul> 				
<li><a href="#">Lien 1</a></li> 
<li><a href="#">Lien 2</a></li>
<li><a href="#">Lien 3</a></li>
</ul>

plutot que celui ci:

<a href="#">Lien 1</a>
<br />
<a href="#">Lien 2</a>
<br />
<a href="#">Lien 3</a>
<br />

Question:
Pourquoi ?
Merci.
Modifié par hadith (16 Mar 2009 - 16:12)

Réponse : parce que sémantiquement parlant c'est plus logique.

L'aspect graphique est bien sûr mis de côté puisqu'il pourra être géré comme voulu grace au CSS et que des résultats similaires peuvent être obtenus avec les deux solutions.

Par contre les listes ont l'avantage de structurer l'information, on sait que tous les éléments de la liste appartiennent à la même tntité "menu". Cette liste sera également un avantage pour les utilisateurs de lecteurs d'écran qui pourront savoir de combien d'éléments est constituée la liste (avec les br c'est pas possible).

De plus si jamais tu veux modifier le look de ton site et le mettre sur une ligne au lieu d'en colonne, pas besoin de modifier le code avec les listes, quelques modifications dans le fichier CSS et c'est fait. Alors qu'avec les br...

Bref, des raisons y en a plein. Et j'en oublie.

Merci, c'est assez clair et convaincant.
Bonne journée.

Bonjour,

1. Pas vraiment plus logique en termes de sémantique, mais l'usage d'une liste non ordonnée est une convention.
2. Un code HTML plus riche, structuré sur trois niveaux (conteneur UL, items LI, liens A). Plus de possibilités de mise en page.

Florent V. a écrit :

1. Pas vraiment plus logique en termes de sémantique, mais l'usage d'une liste non ordonnée est une convention.

C'est ce que je me suis immédiatement dit quand j'ai lu que les liens étaient imbriqués dans des listes pour des raisons sémantiques. Alors qu'au final ça arrange bien pour le second point. (Je dis ça, je fais pareil )

Florent V. a écrit :

2. Un code HTML plus riche, structuré sur trois niveaux (conteneur UL, items LI, liens A). Plus de possibilités de mise en page.

Est ce que ça va apporter une information que le menu soit contenu dans une liste?

bzh a écrit :
Est ce que ça va apporter une information que le menu soit contenu dans une liste?

Bah non. J'ai dit que c'était pas de la sémantique, mais une simple convention.

On peut gloser sur «un menu est une liste de liens», mais en dehors de l'intérêt d'un balisage riche (argument pragmatique, rien à voir avec la sémantique) et d'une séparation contenu/mise en forme un peu meilleure, ça n'est pas supérieur à «un menu est une série de liens séparés par des BR/des puces/ce qu'on veut».

Comme je le disais, c'est aussi une convention. Si elle est suffisamment appliquée (majorité de sites), un utilisateur de lecteur d'écran peut reconnaitre un menu de navigation au fait que ce soit une liste, placée sans doute en début ou fin de contenu, et contenant des liens. Mais l'utilisation d'une liste ou de tout autre balisage ne donne aucune information fiable en ce sens.

Pour info, dans HTML5 il est prévu un élément pour marquer la navigation principale: NAV. Dedans, on mettra... ce qu'on veut, par exemple une liste non ordonnée.
http://www.w3.org/TR/html5/semantics.html#the-nav-element

L'avantage des listes, c'est qu'on peut les manipuler avec beaucoup de facilité en CSS ... ce qui n'est pas le cas de la balise <br /> (que j'évite d'utiliser au maximum ...)

Florent V. a écrit :

Si elle est suffisamment appliquée (majorité de sites), un utilisateur de lecteur d'écran peut reconnaitre un menu de navigation au fait que ce soit une liste, placée sans doute en début ou fin de contenu, et contenant des liens.

C'est dans ce sens la que je l'entendais.

Thibow a écrit :
ce qui n'est pas le cas de la balise <br /> (que j'évite d'utiliser au maximum ...)

Il n'y a pas à éviter <br> "au maximum", c'est un élément HTML tout à fait sain prévu pour forcer un retour à la ligne au sein d'un paragraphe. La succession de 2 <br> par contre est un non sens.

Un autre avantage:
une liste est présentée plus clairement (bullets + affichage vertical) en l'absence de CSS ou dans un navigateur texte.

Florent V. a écrit :

1. Pas vraiment plus logique en termes de sémantique, mais l'usage d'une liste non ordonnée est une convention.

Ben si quand même un peu (au sens HTML), certes c'est basique et peu explicite sur la nature du contenu mais ça défini une liste tout simplement (comme on peut définir un paragraphe, une citation, etc).
C'est de la sémantique HTML toute bête pas de la vrai sémantique qui apporterait un sens véritable au contenu.
Modifié par Hermann (18 Mar 2009 - 14:48)

La sémantique est la science qui étudie et décrit les significations, point barre. Que celle de HTML soit rudimentaire et faiblarde ne lui dénie pas le droit d'en être une à part entière. L'appelation "web sémantique" est venue f... la pagaille en confondant sémantique du métalangage et sémantique des contenus.
HTML étant un métalangage encadrant des contenus (eux-mêmes dotés de leurs propres significations dont peut traiter la sémantique des langages humains), il possède bel et bien sa sémantique. <li> dit liste, ni plus ni moins. Ça n'a pas à qualifier le contenu, ça dit juste qu'il est présenté en liste parce que l'auteur a jugé que c'était la façon la plus juste de représenter la conception qu'il a de ce qu'il met en ligne. Qu'il se trompe est un autre problème.

<p> ou <li> ? On peut aussi pourquoi pas concevoir le tout en terme de "document virtuel" (le site complet considéré comme un seul document, mais présenté morcelé pour des raisons d'utilisabilité) et proposer les liens comme étant des titrages <h> chapeautant/englobant des contenus qui n'auraient pour seule caractéristique que d'être momentanément absents.
C'est la logique que j'ai retenue dans l'outil présenté dans la rubrique Mobiles qui propose pour les petits écrans des <h3><a> appelant au clic des sous-contenus (<h4>,<p>,<img>...) qu'on n'affiche pas pour limiter les temps et volumes de datas à passer. C'est donc un véritable menu en <h> qui ne me pose aucun problème sémantique puisque ça dit juste que derrière s'étageront des contenus en relation avec le titre qui les appelle et les contient. Au départ je remplaçais les <h3> par des <p> mais finalement ça avait moins de sens...

Je crois que tout ça est une histoire de contexte d'utilisation et qu'il n'y a pas forcément de règle autre que celle de la restitution d'une "volonté auteur" qui choisit en connaissance de cause d'organiser son truc comme ci ou comme ça.

a écrit :
Je crois que tout ça est une histoire de contexte d'utilisation et qu'il n'y a pas forcément de règle autre que celle de la restitution d'une "volonté auteur" qui choisit en connaissance de cause d'organiser son truc comme ci ou comme ça.

Bonjour,

Voila quelque chose qui met tout le monde d'accord je pense.

Thibow >

Ca dépend pour qui tu codes et dans quel but, s'il s'agit de ton site personnel, suit ce qui te semble le plus ordonné afin de pouvoir t'y retrouver lors d'une relecture ultérieure.

Toutefois, si tu as un cahier des charges où il est indiqué que tu dois passer la main pour la maintenance du site, ou tu penses ne pas être l'acteur principal de la maintenance, dans ce cas, il est judicieux de respecter ce qui a été établit au préalable. Ou de penser aux collègues qui vont vient derrière.

Après tant que c'est validé, sémantiquement tout est correct, ta logique l'emporte sur le reste puisque c'est l'outil que tu seras amener à utiliser de nouveau pour retravailler dessus. Favorise la, plutôt que de vouloir te rapprocher d'une méthodologie appartenant à autrui.
Voila c'est le seuil conseil que je peux donner, et cela ne fait pas office de parole d'or.

a écrit :
Je crois que tout ça est une histoire de contexte d'utilisation et qu'il n'y a pas forcément de règle autre que celle de la restitution d'une "volonté auteur" qui choisit en connaissance de cause d'organiser son truc comme ci ou comme ça.

Bonjour,

Voila quelque chose qui met tout le monde d'accord je pense.

Thibow >

Ca dépend pour qui tu codes et dans quel but, s'il s'agit de ton site personnel, suit ce qui te semble le plus ordonné afin de pouvoir t'y retrouver lors d'une relecture ultérieure.

Toutefois, si tu as un cahier des charges où il est indiqué que tu dois passer la main pour la maintenance du site, ou tu penses ne pas être l'acteur principal de la maintenance, dans ce cas, il est judicieux de respecter ce qui a été établit au préalable. Ou de penser aux collègues qui vont venir derrière.

Après tant que c'est validé, sémantiquement tout est correct, ta logique l'emporte sur le reste puisque c'est l'outil que tu seras amener à utiliser de nouveau pour retravailler dessus. Favorise la, plutôt que de vouloir te rapprocher d'une méthodologie appartenant à autrui.
Voila c'est le seuil conseil que je peux donner, et cela ne fait pas office de parole d'or.
Modifié par artistik (04 Apr 2009 - 00:38)