<select> vs. <ul>

Bonjour,

Une question toute bête (mais qui attend une réponse éclairée ):
La différence entre un <select> et un <ul> réside-t-elle uniquement dans la présentation (liste déroulante ou non)?

Parce qu'au final, sémantiquement parlant, comment faire un choix entre ces deux éléments?

J'ai bien essayé de chercher sur les spécs w3c chez la-grange.net, mais sans grand résultat.
Merci pour vos avis!

salut,
bin un <select> est utilisé pour un formulaire afin de récolter des informations tandis qu'un <ul> est une liste non ordonnée qui n'a rien à voir avec l'élément précédent. Je pense qu'il n'y a pas d’ambiguïté et le choix est vite fait.

Oui bien sûr...
Mais pour aller plus loin:
- un select donne l'accès par formulaire
- un ul peut donne l'accès par une liste de lien
Donc fonctionnellement on a bien deux solutions possibles pour un même résultat (puisqu'on peut aussi passer des informations par des variables dans le cas d'un <ul>).

Pour moi ça n'est pas assez clair sur le meilleur choix sémantique

Bonjour,
Si tu mets un <select> dans un formulaire, et que tu envoies ce formulaire, la valeur de ce <select> va passer comme paramètre vers la cible du formulaire.

Un <ul> ne va pas te permettre de sélectionner une ou plusieurs valeurs qui seront ensuite envoyées lorsque tu valides le formulaire. (Sauf si tu programmes cette fonctionnalité en javascript).

Le <select> fait parties des contrôles utilisables dans un formulaire, <ul>, non.

Pas sûr qu'il faille aller plus loin.

Tiens, les "edit" font des insert.


Bonjour,
Si tu mets un select dans un formulaire, et que tu envoies ce formulaire, la valeur de ce select va passer comme paramètre vers la cible du formulaire.

Un ul placé dans les mêmes conditions ne va pas te permettre de sélectionner une ou plusieurs valeurs qui seront ensuite envoyées lorsque tu valides le formulaire. (Sauf si tu programmes cette fonctionnalité en javascript).

Le select fait parties des contrôles utilisables dans un formulaire, non.

Pas sûr qu'il faille aller plus loin.
Modifié par loicbcn (13 Nov 2013 - 14:40)

Je pense que c'est très clair. Un <ul> n'est pas fait pour envoyer des variables via un formulaire dans le cas où un <select> doit être utilisé. Je n'arrive même pas à imaginer une situation où tu serais confronté à un pareil choix tant les deux éléments n'ont rien à voir les uns avec les autres.

@zelasan , inavouable : un menu déroulant pour IE6 !

gc-nomade a écrit :
@zelasan , inavouable : un menu déroulant pour IE6 !

?!?

J'adhère globalement aux avis précédents.

Je rajouterais que :

1 - Si tu en viens à remplacer un <select> dans un formulaire par un <ul> et une bidouille javascript quelconque pour que le serveur ne voie pas de différence une fois le formulaire envoyé, pose-toi sérieusement la question de ce que ça peut apporter au niveau accessibilité, ergonomie et utilisabilité. Les <select> sont accessibles à la base, tout le monde les reconnaît immédiatement comme tels et leur comportement d'enroulement/déroulement est parfaitement connu. Trouve-moi un script qui arrive à imiter exactement un <select>, autant au niveau de l'universalité, de l'apparence, du comportement que de l'accessibilité; tu n'en trouveras pas, tous ceux qui existent sont plus ou moins imparfaits. Rien qu'au niveau de l'accessibilité, le plus beau et le plus abouti des bidules conforme ARIA n'arrivera jamais à la cheville d'un vrai <select> (ou en tout cas j'en ai jamais vu des suffisament convainquants qui marchaient optimalement dans la plupart des configurations)

2 - Cas inverse: si tu en viens à remplacer un <ul>, une liste de liens comme tu le supposes, par un <select>, pose-toi les mêmes questions. IL me semble que les menus de navigation à base de <select> ont suffisament été débattus pour qu'on ne songe même plus à les utiliser aujourd'hui.

Donc, vraiment, je ne vois pas dans quels cas tu pourrais hésiter, la différence est très claire: <select> s'utilisent dans les formulaires ou les applications dynamiques lorsque l'utilisateur doit faire un choix, une sélection. Les <ul> en tant que listes de liens s'utilisent dans la navigation ou lorsqu'on n'est pas en contexte de formulaire ou d'application dynamique.

Au cas où, un <select> n'est pas nécessairement un menu déroulant. Ca peut être une zone de liste classique où l'utilisateur peut éventuellement sélectionner plusieurs éléments.
<select size="10" multiple>...</select>
D'ailleurs je crois que cette possibilité a été totalement oubliée des développeurs en 2013... ça fait très longtemps que je n'en ai plus croisé en tout cas.
Modifié par QuentinC (13 Nov 2013 - 17:29)

@QuentinC> Surtout que ça ne sert à rien de réinventer la roue et comme tu le dis pour ne pas la faire parfaitement ronde.

@gc-nomade> IE6 (R.I.P)... Je te l'accorde qu'à une époque il y avait pas trop le choix mais de nos jours !

Le contexte:
Je reprends un site existant (adresse non-diffusable ), qui propose 3 <select> avec du javascript pour changer de page au déroulement de la liste déroulante (donc sans bouton <submit>, je sais que ça a été mal fait, mes précos n'ont pas été suivies). On est dans un cadre de navigation...
Un audit externe sur le SEO a été fait et sur ce point là, la boîte qui a fait l'audit préconise d'enlever les <select> et leur javascript (là, je suis d'accord) pour remplacer le tout par des <ul> (là, je suis moins d'accord). Il me semble effectivement que le <select> (avec un submit) sert à ça, mais j'ais du mal à l'argumenter...

Vos avis éclairés (si, si ) ont apportés de l'eau à mon moulin!
Modifié par speedlab (13 Nov 2013 - 17:47)

jb_gfx a écrit :
?!?

d'autres raisons pratiques pour un novice mal conseillé ou mal documenté ?
Raison encore vue il n' y a pas longtemps sur un forum francophone pour se passer de js, mais le lien ne fonctionnait pas dans <option> , on se demande

gc-nomade a écrit :

d'autres raisons pratiques pour un novice mal conseillé ou mal documenté ?
Raison encore vue il n' y a pas longtemps sur un forum francophone pour se passer de js, mais le lien ne fonctionnait pas dans &lt;option&gt; , on se demande

<edit> grillé et pas fait exprés

@speedlab
En effet , si il s'agit de "navigation", on se tourne vers des liens. L'usage des select pour ce genre de choses avait était détourné au début du web et a perduré lorsque IE dominé le web.

Si tu tiens a conservé ce type de navigation , autant le faire dans un <form> et un submit . Si js , tu cache le submit et ajoute l'evenement onclick sur tes <option>. Les liens peuvent etre suivi par les moteurs de recherche, les formulaires c'est différent

Quelle raison t'incite a vouloir le garder ?
Modifié par gc-nomade (13 Nov 2013 - 18:05)

a écrit :
Si js , tu cache le submit et ajoute l'evenement onclick sur tes <option>.

Et ceux qui ont js activé et qui naviguent au clavier ?
Sur certains navigateurs, enter n'envoie pas le formulaire si on est dans une liste déroulante.

Et je crois aussi me souvenir que onclick sur un <option> ne marche pas sur IE.

Donc non, il ne faut pas masquer le bouton submit.

QuentinC a écrit :
Si js , tu cache le submit et ajoute l'evenement onclick sur tes &lt;option&gt;.

Et ceux qui ont js activé et qui naviguent au clavier ?
Sur certains navigateurs, enter n'envoie pas le formulaire si on est dans une liste déroulante.

Et je crois aussi me souvenir que onclick sur un <option> ne marche pas sur IE.

Donc non, il ne faut pas masquer le bouton submit.

Voila qui est un argument utile et fiable.

Pourtant, cacher le submit en left:-9999px en fixed ou absolute (et pas display:none; ), ne me semble pas un soucis niveau accessibilité, il prendra le focus via tab et la touche enter fera son effet, ou bien je n'ai jamais compris comment cela fonctionne ?

speedlab a écrit :

Un audit externe sur le SEO a été fait et sur ce point là, la boîte qui a fait l'audit préconise d'enlever les &lt;select&gt; et leur javascript (là, je suis d'accord) pour remplacer le tout par des &lt;ul&gt; (là, je suis moins d'accord). Il me semble effectivement que le &lt;select&gt; (avec un submit) sert à ça, mais j'ais du mal à l'argumenter...

Pour en revenir à la question:
Pour une navigation, pour le référencement l'accessibilité, etc. on utilise des liens avec la balise <a>. C'est le plus vieux principe du web (le principe fondateur même). Tous les robots explorateurs et systèmes d'aide reconnaissent facilement ce système, ça permet aussi de copier l'adresse, de l'ouvrir dans une autre fenêtre/onglet, de copier/coller dans un autre document et garder le lien, etc. Lorsqu'on a une liste de lien on met ça dans un <ul>, car c'est l'élément dédié aux listes.
Un select est un élément de formulaire, un élément qui sert donc à saisir des données, afin de les traiter. Les différents user-agents peuvent l'implémenter librement selon l'appareil ou les conditions d'utilisation. Si le seul but de ce select est d'introduire une navigation, cela est complètement inadapté et pose plein de problèmes alors que la première balise de l'histoire du web est faite pour cela.

a écrit :

[...] ne me semble pas un soucis niveau accessibilité, il prendra le focus via tab et la touche enter fera son effet, ou bien je n'ai jamais compris comment cela fonctionne ?

Tu as probablement bien compris comment ça fonctionne, mais par contre si, ça peut quand même poser des problèmes d'accessibilité.

Utilisateur du clavier ne veut pas nécessairement dire lecteur d'écran, tout comme lecteur d'écran ne veut pas nécessairement dire non-voyant non plus.

Essaie d'utiliser un logiciel loupe comme Zoom Text en agrandissant à 3-4x ou plus. Tab a un effet bien pratique, il déplace le focus et donc la loupe au bon endroit, alors qu'à la souris tu dois aller chercher le bouton ou ouvrir les zones déroulantes puis sélectionner avant que ça se referme (pas si facile si le facteur d'agrandissement est grand).

Une autre blague, c'est que si tu as un élément focusable mais caché, tu as deux possibilités :
- Soit le navigateur décide de le faire réapparaître quand il prend le focus et le faire redisparaître lorsqu'il perd le focus. De un ça fait nécessairement un saut inattendu, et de deux l'endroit de la page où ça se passe est potentiellement indéterminé
- Ou alors soit le navigateur ne fait pas réapparaître l'élément lorsqu'il est focusé, et dans ce cas la question est où suis-je, où est le focus, je ne vois rien, c'est nul ce site ça marche pas

Donc moralité, on n'envoie pas les éléments focusables hors écran.

Après, bon, pour une navigation secondaire, répétitive et optionnelle, dans certains cas ça peut s'imaginer, avec un simple onchange ça reste plus accessible que tout un bronx de menu déroulant. C'est le cas par exemple du «aller à» ici en bas du forum. Mais à utiliser avec parcimonie et surtout pas pour la navigation principale du site.

Onchange, non, c'est à proscrire aussi. Avec IE, entres autres, l'envoi du formulaire est immédiat après avoir appuyé sur une touche. Donc pas possible de se déplacer dans la liste avec haut/bas, et pour certains c'est même trop rapide pour ne serait-ce qu'entendre l'élément qui a été juste sélectionné avant envoi.

QuentinC http://forum.alsacreations.com/topic-2-69646-1-ltselectgt-vs-ltulgt.html#p466547 a écrit :
...

Donc moralité, on n'envoie pas les éléments focusables hors écran.

voilà qui éclaire bien ma lanterne, merci
Modifié par gc-nomade (14 Nov 2013 - 17:47)