Un <hr/> dans un <ul>, mauvais code ?

Bonjour,

Je voulais me renseigner histoire d'être sûr.

Est-il correct d'écrire ce code (je vise en particulier les <hr/> dans le <ul>) :

<ul>
  <hr/>
  <li>Something</li>
  <li>Something</li>
  ...
  <hr/>
</ul>

C'est bien ce que je craignais. J'étais tenté par insérer un <hr> là-dedans de façon à tout rassembler et ainsi avoir un code (un peu) plus lisible.

Mais on ne rigole pas avec les règles !

Merci !

Sls a écrit :
Mais on ne rigole pas avec les règles !

Et puis surtout ça sert à rien comme code.

- Si c'est pour de la décoration, fais-le en CSS, pas besoin d'éléments HR.
- Si c'est pour signifier le début et la fin de ta liste et ainsi la séparer du reste, bah l'élément UL joue déjà ce rôle.
- Si c'est pour séparer des groupes de LI de natures différentes, peut-être envisager d'utiliser plusieurs listes plutôt qu'une seule.

je répond avec un peu de retard mais ça m'interpelle:

Ce ne serait pas si inutile, avoir une balise de séparation, pour résoudre ce genre de cas:

ou dans une liste d'icônes (séparation verticale).

habituellement on utilise facilement un li vide genre:

<li class="separator"></separator>

le hr serait bien entendu inapproprié vu qu'il est un élément graphique et non sémantique. Mais d'avoir un <sep /> ou au contraire un <group><li></li><li></li> ... </group> pourrait être très utile

kustolovic a écrit :
Ce ne serait pas si inutile, avoir une balise de séparation, pour résoudre ce genre de cas:
upload/32231-Capturede7.png

Alors là je vois VRAIMENT pas le rapport.

kustolovic a écrit :
ou dans une liste d'icônes (séparation verticale)

Non.

kustolovic a écrit :
habituellement on utilise facilement un li vide

Si c'est habituel alors c'est une bêtise habituelle. À éviter.

kustolovic a écrit :
le hr serait bien entendu inapproprié vu qu'il est un élément graphique et non sémantique

Dans HTML 4 (1998), HR est défini comme un élément graphique, en effet: “The HR element causes a horizontal rule to be rendered by visual user agents.” J'imagine que c'était essentiellement dû à l'historique de HTML et la grande jeunesse de CSS (1997). En HTML5 il est très logiquement redéfini avec une valeur sémantique: “The hr element represents a paragraph-level thematic break”, ce qui correspond bien aux usages modernes de cet élément (et à une grande partie des usages plus anciens).

kustolovic a écrit :
avoir un <sep /> ou au contraire un <group><li></li><li></li> ... </group> pourrait être très utile

L'élément SEP proposé n'est pas nécessaire car:
- La simple limite entre deux éléments frères est déjà une séparation.
- L'élément HR existe déjà et réponds à certains cas d'usage.
- D'autres cas d'usage pourront être réglés en utilisant les éléments HTML existant déjà pertinents: P, LI, A, DIV, SECTION, ARTICLE et d'autres encore.

Quand à l'élément GROUP, je ne vois pas en quoi il serait différent de UL. Pour quels cas d'usage et quels contenus serait-il nécessaire?

fvsch a écrit :

Alors là je vois VRAIMENT pas le rapport.

L'image a changé Oo Il montrait avant une barre de menus avec des séparateurs pour faire des regroupements de fonctions.

Gothor a écrit :
une barre de menus avec des séparateurs pour faire des regroupements de fonctions

Deux solutions vu l'état actuel des specs:
- Soit tu considères que ces regroupements sont une petite optimisation ergonomique et ne sont pas essentiels, et tu ne les représente pas dans le code HTML.
- Soit tu considères que ces regroupements sont importants et dans ce cas tu utilises des éléments pour regrouper les fonctions qui vont ensemble.

Dans le deuxième cas, ça peut donner pour de la navigation:

<nav>
  <ul>
    <li>A1</li>
    <li>A2</li>
    <li>A3</li>
  </ul>
  <ul>
    <li>B1</li>
    <li>B2</li>
  </ul>
</nav>

Variante, si les regroupements ont un libellé visible: des listes imbriquées.

Ceci dit, je note que la spec HTML5 donne un exemple de MENU qui utilise un HR. Schématiquement:

<menu type="toolbar">
  <command />
  <command />
  <command />
  <hr />
  <command />
  <command />
</menu>

kustolovic a écrit :
Bah en même temps on voit ça souvent, et la séparation a un sens sémantique.

On voit souvent des codes avec des erreurs plus ou moins importantes, oui.
La séparation a un sens, mais la sémantique utilisée pour le transmettre est fausse. C'est aussi simple que ça.