18100 sujets

Questions générales et questions de débutants

Menus CSS, <ul><li> versus <div>

Pages :
Bonjour.
Je me permet d'ouvrir un thread car j'aimerais avoir votre opinion.

La première fois que j'ai vu un menu horizontal construit avec des <li>, j'ai trouvé celà très astucieux. Néanmoins, les problèmes de compatibilité entre les navigateurs soulèvent des problèmes.

En effet, les balises <ul> et <li> sont spécialisées, et leur utilisation implique de surcharger des propriétés comme celle qui gère les puces.

La question que je me pose est, pourquoi n'utilise t'on pas simplement des <div> en remplacement. En effet, les <div> sont d'utilisation plus générale, et plus facile à vivre.

Ainsi, un menu peut être défini comme suit:


<div class="mon_menu">
	<div><a href="#">Première option</a></div>
	<div><a href="#">Deuxième option</a></div>
	<div><a href="#">Troisieme option</a></div>
</div>


et les styles css comme suit:

version menu vertical
.mon_menu {text-align:left;width:80%;background-color:inherit}
.mon_menu div {padding-bottom:4pt;display:block}
.mon_menu a {text-decoration:none; font-family:tahoma; font-size:8pt; font-weight:bold; color:navy; padding-left:10pt; padding-right:10pt}
.mon_menu a:hover { background-color:yellow;color:white}


version menu horizontal
.mon_menu {text-align:left;width:80%;background-color:inherit}
.mon_menu div {padding-bottom:4pt;display:inline}
.mon_menu a {text-decoration:none; font-family:tahoma; font-size:8pt; font-weight:bold; color:navy; padding-left:10pt; padding-right:10pt}
.mon_menu a:hover { background-color:yellow;color:white}


... seule la propriété display est choisie entre block et inline

On limite grandement les différentes interprétations entre les navigateurs.

Qu'en pensez-vous ? et que voyez vous comme inconvénients...
Euh, rien n'empêche d'utiliser le display: inline; sur les <li> ce qui résoud le problème des puces Smiley ohwell
Et changer la structure du code HTML pour une simple ligne de CSS, ça me paraît hasardeux comme façon de procéder...

Un menu est une liste de lien, c'est pourquoi on n'utilise classiquement une liste non ordonnée pour baliser les menus, il n'y a pas mieux à notre disposition.

En tout cas, je ne vois pas l'interêt d'utiliser des <div> en lieu et place d'une liste Smiley ohwell

Bien sûr rien n'empêche de le faire mais ça me paraît moins bon.
De même à l'affichage sans styles CSS, une liste présentera mieux qu'un enchainement de <div> et sera plus claire, dans un navigateur texte encore plus.

Je ne comprend pas tes arguments en tout cas Smiley ohwell
Bonjour,

GeorgesM, ce que tu dis ci-dessus est tout à fait vrai... dans le contexte très étroit des navigateurs graphiques avec support CSS et sans exigences spécifiques de l'utilisateur exprimées via une application supplémentaire (lecteur d'écran, CSS ou script utilisateur, etc.)

C'est à dire une toute petite partie du Web. Vraiment toute petite, et qu'on ne pourrait honnêtement considérer comme tournée vers l'avenir.
Modifié par Un vacancier (28 Aug 2005 - 11:35)
Merci pour vos réponses, elles vont m'aider à me forger une opinion.

Je suis d'accord avec ce qui suit :

a écrit :
De même à l'affichage sans styles CSS, une liste présentera mieux qu'un enchainement de <div> et sera plus claire, dans un navigateur texte encore plus.


Effectivement, en html pur, ul et li sont ce qu'il y a e mieux pour figurer une liste : tout est préparé (balises spécialisées) marge gauche de ul, puces de li, et numérotation avec ol.

Mais le sujet porte sur la définition de menu avec CSS, et dans ce cas, les fonctionnalités html sont surchargées pour justement suprimer les puces, et les marges indésirables.

Bien sur, les puces sont suprimées automatiquement avec inline, mais elles subsistent avec les menus verticaux.

Une fois ces deux propriétés surchargées, on se retrouve avec des balises ayant le même comportement qu'une div.

Je pense que la démarche de suprimer les tableaux est bonne car elle vise à suprimer des balises html spécialisées, et les remplacer par des balises générales (span, div) dont le contrôle est réalisé via CSS.

a écrit :
... est tout à fait vrai... dans le contexte très étroit des navigateurs graphiques ...


Oui. Je parlais effectivement des menus CSS dans le cadre étroit des milliards de pages qu'on regarde sur un ecran avec un navigateur.
Mais quand les frigos serront branchés sur la toile, il faudra tout de même des menus pour choisir son supermarché ! (lol)
Oulaa, non non, c'est pas la façon de procéder ça !

Tu te focalises sur le rendu par défaut sur les navigateurs graphiques pour réaliser ton code HTML, ce n'est pas la démarche à employer.

Tu dois réaliser ton code HTML indépendament de sa mise en forme, tu n'a a aucun moment besoin de prendre en compte la mise en forme pour réaliser le code HTML. Une fois arrivé à la mise en forme, on peut réajuster le code HTML pour ajouter des identifiant, des class, des balises génériques.

Et se dire qu'il y a 3 pauvres propriétés sur les listes à changer donc on va prendre une balise HTML qui n'a aucune mise en forme, c'est stupide Smiley ohwell

Ah, bah non, je ne vais pas mettre un titre <h1>, il a des marges, il a une forte graisse, et une taille de police élevée, je vais mettre une <div> qui n'a pas tout ça.

a écrit :

les fonctionnalités html sont surchargées pour justement suprimer les puces,


Ah ? code HTML surchargé ??

donc on a dans le coin gauche :

<div>
<div>...</div>
<div>...</div>
</div>

et dans le coin droit

<ul>
<li>...</li>
<li>...</li>
</ul>


Hmm, ahh bah y a même moins de lettres pour <ul><li> Smiley langue

Et tu confonds là, tu mélanges encore HTML et mise en forme.

Franchement, tu ne prends pas le problème dans le bon sens.
Et c'est justement le fait de se focaliser sur le rendu par défaut dans les navigateurs graphiques qui pose problème.

Et je le répète, c'est pas 3 pauvres lignes de CSS qui vont tuer le président, c'est quedal dans une CSS.

Et la suppression des tableaux de présentation n'équivaut pas à les remplacer par des balises générique !!! NON NON et NON !

Il s'agit d'utiliser une balisage sémantique complété par quelques balises génériques pour regrouper les éléments et aider à la mise en forme.
Modifié par Olivier (28 Aug 2005 - 12:20)
C'est interessant...

a écrit :
Hmm, ahh bah y a même moins de lettres pour <ul><li>


Je suis d'accord avec ça. Il y a une lettre de moins. Dans le coin gauche, il y a une balise au lieu de deux.

Bien sur, ce n'est pas trois lignes de CSS en plus qui changent grand chose.

Pardonnez moi, mais je trouve certains arguments assez conservateurs.

Franchement, tu ne prends pas le problème dans le bon sens.
Et c'est justement le fait de se focaliser sur le rendu par défaut dans les navigateurs graphiques qui pose problème.


Quel problème ? Les navigateurs sont, depuis le siècle dernier, graphiques, et ils ont toutes les chances de le rester encore quelques temps, donc la dimension mise en forme et présentation fait partie intégrante de la démarche, et il est normal de se pencher sur ces questions..

Ok. Faisons le point.
Dans le cas d'un menu horizontal, on détourne la balise <li> car celle-ci est définie LI { display: list-item }, et n'est donc pas faite pour cet usage. Dans le cas d'un menu vertical, c'est plus adapté, mais la plupart des menus sont présentés sans puces.

Manifestement, on trouve que c'est pas bien d'utiliser une balise neutre pour remédier à celà.

Mais, quels sont les inconvénients et les problèmes posés par <div>?

PS: Sur des gros documents hiérarchisés avec H1, ... H6, une modification de structure induit des problèmes.
L'utilisation de <div class="un_niveau_abstrait "> permet de s'afranchir de la rigidité de H1...
Le problème avec l'utilisation des div, dans ce cas-ci, c'est que tu utilises une balise qui n'a pas de sens du point de vue sémantique alors qu'il existe une autre balise, ul, qui a justement la signification recherchée ! (je crois que tu es d'accord avec le fait qu'un menu est une liste de liens. Donc utilise la balise de liste, point.)

Après, la mise en forme, tu pourrais aussi bien la réaliser avec des <p> ou des <hn> qu'avec des <div>, de toutes façons tu es à côté de la question Smiley cligne
Modifié par Sopo (28 Aug 2005 - 14:13)
Encore non et non Smiley smile

Tu dis que le display: inline; dénature l'item de liste...
Non, c'est faux, tu fais fasse à une ambiguité.

display: block; en CSS et un élément de type block même si souvent ça se recoupe, ce n'est pas lié. Les CSS ne font que modifier le rendu d'affichage des éléments, ils ne changent pas la nature des éléments.

Prenons un exemple :

<span><p>..</p></span>


C'est invalide car <p> est de type block et <span> de type inline.
Tu auras beau faire span { display: block; } et p { display: inline; } ça ne changera rien, le document sera toujours invalide et tu n'auras en aucun cas changé la nature des éléments mais uniquement leur affichage.

Ici c'est pareil.
Par ailleurs, tu peux linéariser des listes avec float: right/left; ce qui règles la question de la légitimité des listes pour les menus en ligne.

A la limite, je veux imaginer qu'on puisse utiliser des <div> pour baliser un menu, mais tes arguments ne sont pas bons, comme je te le disais, tu prends le problème à l'envers, et je ne vois rien qui indiquer qu'il vaille mieux utiliser <div> qu' <ul><li> au contraire même !
Puisqu'<ul> indiquer que c'est une liste de lien.

Pour ce que tu dis au sujet de notre "conservatisme", justement encore NON !!!!

En procédant ainsi (en structurant notre code HTML indépendament du rendu CSS, et de façon sémantique), nous permettons à n'importe quel navigateur ou agent utilisateur d'accéder au contenu de façon claire.

Certe les navigateur sont graphique la plupart du temps, mais il n'y a pas que ça, et ça tend justement à diminuer, ou plutôt la part des agents utilisateur non graphiques tend à augmenter.
Les PDA, les navigateur mobiles, les navigateurs texte, les plages brailles, les navigateurs vocaux et j'en passe.

C'est justement assez novateur à côté des sites bourrés de tableaux imbriqués, de <font> etc qui rendent les pages incompréhensible dans les agents utilisateurs "marginaux".

Tout ton argumentaire est basé sur le rendu CSS alors qu'on s'en fout totalement dans le choix du balisage d'un contenu Smiley cligne
Merci à Sopo pour sa réponse.

Je vois que l'aspect point de vue sémantique l'emporte sur les critères purement techniques.
Je comprend et respecte cette opinion.
La démarche vise à rendre lisible par l'humain des pages html et de permettre leur exploitation par d'autres programmes (xsl).

Personnellement, je n'écris pas d'html depuis un bout de temps, et à fortiori, je ne le lis pas non plus directement.

Le style de code que j'écris ressemble plutôt à ce qui suit.


<menu id="w_menu">
	<title>menu</title>
	<btn><!-- Accueil -->
		<action>
<step name="clear" delay="100" container="main_pan"/>
<step name="clear" delay="100" container="left_4"/>
<step name="clear" delay="100" container="left_3"/>
<step name="clear" delay="100" container="left_2"/>
<step name="load" delay="250" container="main_pan" content="content/intro.xml" fragment="intro"/>
		</action>
		<label>
			<txt lang="fr">Accueil</txt>
			<txt lang="en">Home</txt>
		</label>
		<tooltip>
			<txt lang="fr">Page principale</txt>
			<txt lang="en">Home page</txt>
		</tooltip>
	</btn>

	<btn><!-- fonctionalités -->
		<action>
			<step name="clear" delay="100" container="left_4"/>
			<step name="clear" delay="100" container="left_3"/>
			<step name="clear" delay="100" container="left_2"/>
			<step name="load" delay="250" container="left_2" content="content/fonctionalite.xml" fragment="plug_fonctionalite_menu"/>
		</action>
		<label>
			<txt lang="fr">Fonctionalités</txt>
			<txt lang="en">Functionalities</txt>
		</label>
		<tooltip>
			<txt lang="fr">Les fonctionalités</txt>
			<txt lang="en">The functionalities</txt>
		</tooltip>
	</btn>
</menu>


C'est du xml, et obéit à une sémantique propre à sa logique, et reste lisible de bout en bout. C'est compréhensible par l'humain et par la machine. Dans ce cas c'est aussi compréhensible par des humains de Quebec et d'autres de l'Ontario... Smiley cligne

Dans un deuxième temps, je dois traduire ce code xml en un code html lisible par un navigateur, et si possible par deux navigateurs. Donc, mon problème de sémantique est déplacé au niveau du navigateur, étant donné que l'humain ne lira pas le code html généré, et de toute façon le trouvera horrible!

De ce point de vue, les considérations techniques l'emportent sur les autres. Je dois obtenir le meilleur résultat, et le plus portable.

C'est en ce sens que le remplacement des tables par les listes me semblait un bon progrès. En ouvrant ce thread, je suivais cette logique.
a écrit :
C'est invalide car <p> est de type block et <span> de type inline.
Tu auras beau faire span { display: block; } et p { display: inline; } ça ne changera rien, le document sera toujours invalide et tu n'auras en aucun cas changé la nature des éléments mais uniquement leur affichage.


C'est invalide car c'est en infration avec la DTD
Olivier a écrit :
Certe les navigateur sont graphique la plupart du temps, mais il n'y a pas que ça, et ça tend justement à diminuer, ou plutôt la part des agents utilisateur non graphiques tend à augmenter.
Les PDA, les navigateur mobiles, les navigateurs texte, les plages brailles, les navigateurs vocaux et j'en passe.


J'ajouterai que, même si leur part était infinitésimale et décroissante, ils mériteraient quand même qu'on s'en préoccupe, afin de permettre l'accès à internet à tous !

GeorgesM a écrit :
C'est invalide car c'est en infration avec la DTD

Et c'est en infraction avec la DTD parce que ça n'a pas de sens Smiley smile
J'avais oublié, depuis le temps la sémantique exacte :

<menu>
<a href="#">premier</a>
<a href="#">deuxieme</a>
</menu>


... En effet, il faut réserver <ul> et <li> pour les listes, et éviter de les utiliser pour les menus...

... Mais voilà, le w3c le déconseille, et tôt ou tard <menu> disparaîtra, (ou a déjà disparu).
Pour suivre la remarque de Sopo sur les agents non graphiques, j'adhère à ce soucis de s'en préoccuper, mais je vois mal html assumer ce rôle.
En effet, même si l'imbrication span p est absurde, un navigateur se doit de l'afficher quand même.
Le nombre de pages valide est tellement bas, que toute tentative de censurer les contenus html aproximatifs aboutirait à de drôles de résultats..
Pour communiquer avec un agent spécialisé, il faut utiliser un sgml sérieux, avec une dtd sérieuse. Les outils sont XML, XSLT, etc... pas html.
Avec html, on ne fait rien d'autre que de tenter d'afficher des pages sur deux navigateurs.
C'est à la limite CSS qui se chargera de définir comment prononcer ce qui est écrit, (avec accent Anglais), mais CSS n'a aucune notion de balise p div span li, à part <a>, bien entendu.
Toutes les balises html sont soit des <div> (p, ul, li, h1 à h6...) soit des <span> (b, i...) le dom ne fait d'ailleur pas plus de distinction que ça, étant donné que la distinction est block et inline.

Seule la balise <a> est irremplaçable sans script.
Waaooo, faut être accroché là...

Je ne comprend strictement rien de ce que tu racontes...

Le HTML est largement suffisant pour baliser du contenu et lui donner du sens dans un navigateur texte ou autre.

Les balises HTML ne sont pas soit des <div> soit des <span>, c'est totalement absurde...

Il y a des balises de type block et de type en ligne, <div> et <span> en sont une de chaque mais ne définissent pas le type.

... P'tingh, j'arrive même pas à comprendre ce que tu racontes...

Entre approximations, erreurs, mauvaise compréhension etc, on n'y comprend plus un traître mot.

Pour l'exemple du <p> et du <span>, c'était juste un exemple pour expliquer la notion block et d'inline n'était pas liée aux propriétés de style display: block/inline; rien à voir avec un navigateur texte...

Et NON, un navigateur n'a pas forcément à accepter ce code même si invalide, il ne l'acceptera d'ailleurs pas en xHTML (réel).
GeorgesM a écrit :

En effet, même si l'imbrication span p est absurde, un navigateur se doit de l'afficher quand même.
Le nombre de pages valide est tellement bas, que toute tentative de censurer les contenus html aproximatifs aboutirait à de drôles de résultats..

On n'est pas en train de censurer le contenu foireux, on essaie qu'il y en ait un peu moins ! Ce n'est pas parce qu'Alsa et certains membres éminents du forum sont d'ardents défenseurs du xHTML qu'il est interdit de faire ses pages n'importe comment. Seulement, ce n'est pas de ce cas de figure qu'on s'occupe ici.

Etre conforme aux standards, personne n'y est obligé, c'est plutôt un ensemble de règles de bonnes pratiques (enfin, c'est comme cela que je le perçoit) ~plutôt une ligne de conduite, comme dirait Jack Sparrow Smiley lol . Mais quand on veut travailler proprement, et dans tous les métiers, on respecte les règles de bonne pratiques tant qu'on peut.

GeorgesM a écrit :

C'est à la limite CSS qui se chargera de définir comment prononcer ce qui est écrit, (avec accent Anglais), mais CSS n'a aucune notion de balise p div span li, à part <a>, bien entendu.

Là je ne comprend pas de quoi tu parles ... si c'est à propos des lecteurs d'écran, la langue (ou l'accent) à employer est normalement indiquée dans le <head> et dans les liens <a> (donc dans la partie HTML, ça n'a rien à voir avec de la mise en forme, donc rien à faire dans les CSS)

Et pour le reste, je ne sais pas de quoi tu parles. XHTML et CSS c'est pour faire des sites web ... et pour le web, c'est amplement suffisant.
Quand on me parle fort, je me remplis la tête de doute. Désolé pour les erreurs, mauvaises compréhensions...

Donc, j'ai trouvé çà : (html 4)

<!ELEMENT DIV - - (%flow;)*            -- conteneur générique de langue/style -->
<!ATTLIST DIV
  %attrs;                              -- %coreattrs, %i18n, %events --
  >
<!ELEMENT SPAN - - (%inline;)*         -- conteneur générique de langue/style -->
<!ATTLIST SPAN
  %attrs;                              -- %coreattrs, %i18n, %events --
  >



et çà

<!ELEMENT LI - O (%flow;)*             -- item de liste -->
<!ATTLIST LI
  %attrs;                              -- %coreattrs, %i18n, %events --
  >


J'espère ne pas me tromper encore une fois en disant que DIR et LI sont équivalent, à part la close O qui autorise de ne pas fermer la balise.
La propriété TYPE (de LI) n'est pas mentionné dans la DTD. Les navigateurs l'interprètent parce qu'ils le veulent bien...
D'ailleurs, vous et moi pouvons inventer des propriétés, elles seront prises en compte par le dom, sans problème.. et utilisable par les scripts.
Et ainsi, de suite... toute les balises html appartiennent à l'un ou l'autre type de base, et sont enrichis par la DTD de fonctionnalités affinant leur spécificité.
Je ne suis pas sûr de comprendre où tu veux en venir ... mais tu assimiles encore les balises de type bloc et les <div>.

Ce que je lis dans ton post ne fais que comforter ce qui a été dit plus tôt :
Element DIV = conteneur générique
Element LI = item de liste

L'un a un rôle déterminé, l'autre peut contenir n'importe quoi. Il ne sont pas "équivalents", et on ne peut pas les échanger. Ni dans un sens ni dans l'autre.
La DTD dit exactement le contraire ! Ce que vous citez, c'est les commentaires.

C'est important, la DTD, surtout dans un environnement où personne ne la respecte!

Si vous me dites que c'est un problème de sémantique, et uniquement de sémantique alors d'accord, je comprend, et je respecte.
Mais techniquement, je ne vois plus d'objection, alors que ce matin je ne faisais que me poser la question. Si la DTD indique que les deux balises sont identiques, c'est qu'elles le sont. Il ne faut pas être plus royaliste que le roi (le roi w3c j'entend...)
Modifié par GeorgesM (28 Aug 2005 - 17:48)
GeorgesM a écrit :

Oui. Je parlais effectivement des menus CSS dans le cadre étroit des milliards de pages qu'on regarde sur un ecran avec un navigateur.
Mais quand les frigos serront branchés sur la toile, il faudra tout de même des menus pour choisir son supermarché ! (lol)


Et quand les c... seront sur orbite, t'as pas fini de tourner Smiley biggrin

Désolé pour ce qui N'EST PAS une agression ni une insulte : n'y vois qu'une citation cinéphile à laquelle je n'ai pas su résister.

Quand je te parle d'autre chose que des navigateurs graphiques, il s'agit par exemple:
- de lecteurs d'écrans et de navigateurs vocaux, dans lesquels il est apréciable de se voir signaler le passage d'un item de menu à un autre, ce que ton code générique ne provoquera pas
- de navigateurs sans support CSS, dans lesquels ton code aura un rendu par défaut là encore nettement moins explicite pour l'utilisateur
- d'agrégateurs de contenu, dans lesquels... tu as compris, je crois ?

Je pourrais te parler aussi des "frigidaires intelligents", c'est à dire des multiples scripts susceptibles aujourd'hui de s'intéresser à ton contenu, mais je préfère éviter, étant donné la somme de confusions ambiantes.

Je me contenterais de te recommander de ne pas citer les DTD à tort et à travers : elle ne définissent pas l'usage ni l'utilité des éléments, mais uniquement leur syntaxe et leur rôle structurel. En d'autres termes, elles permettent de déterminer le valide et le bien formé, mais pas le "sémantique".

Enfin, le "sémantique" est en réalité, pour HTML, quelque-chose de très concret: est sémantique ce qui sera bien rendu quelque-soit le media, bien exploité quelque-soit le script, conformément aux intentions de l'auteur.

A toi de déterminer tes intentions:
- il y a des cas bien précis où, en effet, une liste HTML n'est pas l'outil approprié.
- mais ils ne justifient pas qu'on remplace bêtement et systématiquement les listes par autre-chose.

Là-dessus, je retourne sous mon palmier.
Modifié par Un vacancier (28 Aug 2005 - 18:42)
Pages :
Sujet clos
Aller à