Enumération et sémantique

Bonjour,

Je m'interroge sur la meilleur facon d'un point de vu sémantique de présenter une liste énumérative du type

categorie : livres
type : manga
auteur : monsieur X
date de parution : 12-12-2006
editeur : xxxx

habituellement je présente ca sous forme de liste

<ul>
  <li><strong>categorie</strong>: livres</li>
  <li><strong>type</strong>: livres</li>
....

ou avec des <span> au lieu du <strong>

mais sémantiquement il doit y avoir mieux non ?

je pensais au <dl> mais on est pas vraiment dans le cas de définitions.

on serait proche d'une représentation en tableau , mais avec 2 colonnes , donc pas vraiment pertinent non plus .

Qu'en pensez vous ?

Merci d'avance.
Modifié par PeterPetrelli (25 Jun 2007 - 07:56)

Salut,

En fait tu donnes déjà toutes les solutions , c'est juste ta conclusion qui n'est pas bonne, à mon sens.
Les <dl> seraient acceptables (elles sont d'ailleurs très souvent utilisées dans de pareil cas), même si effectivement à l'origine c'est dédié aux seules définitions. Tous les cas sémantiques n'ont pas été prévus par les specs html et là on ne s'éloignerait pas tant que ça du sens original.

Mais le plus sémantique est sans aucun doute (toujours en ce qui me concerne) le tableau. Un tableau à deux colonnes est tout à fait valide (je ne comprends même pas pourquoi il ne le serait pas), tout autant qu'un tableau à 78 colonnes. Aucune différence.

[ hs ]
En fait, toutes les listes terme/valeur peuvent ête représentées très justement dans un tableau, y compris les listes de définitions ! Utiliser <table> pour baliser une liste de définitions (avec un entête style <th>Terme</th><th>Définition</th>) est sémantiquement tout à fait correct, c'est juste qu'en utilisant <dl> on est plus précis, on qualifie avec la balise elle-même le type de relation qu'entretient le terme avec la valeur.
[ /hs ]
Modifié par marcv (25 Jun 2007 - 08:37)

marcv a écrit :

[ hs ]
En fait, toutes les listes terme/valeur peuvent ête représentées très justement dans un tableau, y compris les listes de définitions ! Utiliser <table> pour baliser une liste de définitions (avec un entête style <th>Terme</th><th>Définition</th>) est sémantiquement tout à fait correct, c'est juste qu'en utilisant <dl> on est plus précis, on qualifie avec la balise elle-même le type de relation qu'entretient le terme avec la valeur.
[ /hs ]

Non.

Le tableau à deux colonnes est alors un élément générique, par opposition à l'élément spécifique. Seul ce dernier sera le support d'exploitations côté UA répondant à des besoins précis. Cas-types:
- le couple terme/définition du glossaire
- le couple label/contrôle et legend/contrôles des formulaires

<edit>le contenu dont il est question dans ce sujet ne rentre évidemment pas dans cette problématique</>
Modifié par Laurent Denis (25 Jun 2007 - 09:58)

Hello,

PeterPettrelli a écrit :
la meilleur facon d'un point de vu sémantique

marcv a écrit :
le plus sémantique

C'est marrant en fait toutes ces petites discussions sur la sémantique. Ça me donnerait presque envie de demander : pour quoi ou pour qui est-ce que l'on balise sémantiquement ?

Par exemple, si j'ai ceci :

<p>Save the cheerleader; save the world.</p>

La lecture linéaire de cette phrase suffit à dégager la relation de cause à effet. Mais bon, on pourrait être plus « explicite », par exemple en utilisant un tableau :

<table>
	<tr><th>Cause</th><th>Effet</th></tr>
	<tr><td>Save the cheerleader</td><td>Save the world</td></tr>
</table>

ou encore en détournant les listes de définition de leur usage (pas très strictement normé, certes) :

<dl>
	<dt>Save the cheerleader</dt>
	<dd>save the world</dd>
</dl>

Mais bon, ça n'alourdit pas un petit peu par rapport à

<p>Save the cheerleader; save the world.</p>

?


Même réflexion avec :

<li>Catégorie : livres</li>

C'est déjà pas mal explicite comme ça, pour un lecteur humain, que la lecture soit visuelle ou qu'elle se fasse via une synthèse vocale ou autrement. Pas besoin forcément de « sémantiser » tout ça, hein.


Ceci dit, pour les options proposées :
- celle de départ avec la liste non ordonnée me semble très bien ;
- à mon avis, mieux vaut éviter la liste de définitions (on risque de transmettre une information inexacte ou trompeuse... ou bien pas d'information du tout, auquel cas on s'est pris la tête pour rien avec une liste de définitions) ;
- un tableau c'est pas mal, surtout si on souhaitait faire une mise en page en colonnes... mais par contre ça fige les possibilités de mise en page.
Modifié par Florent V. (25 Jun 2007 - 10:00)

Laurent Denis a écrit :
Non encore. Display marche très bien dans ce sens-là dans tous les navigateurs.

Humm... display: table-cell dans tous les navigateurs ? Internet Explorer a été transfiguré dans la nuit ?
(Et je sais bien que les flottants pour IE via commentaires conditionnels ou les flottants pour tout le monde etc., mais on sort du « marche très bien (...) dans tous les navigateurs ».)

Non, là, c'est la démarche inverse: linéariser un tableau HTML dans tous les navigateurs à l'aide de display:block et display:inline; Pas faire un pseudo-tableau avec display:table-cell.

Mais laissons tomber, ce n'est pas pertinent ici.
Modifié par Laurent Denis (25 Jun 2007 - 10:09)

Salut,

je trouve aussi la liste <ul> est très bien, l'important est sans doute que chaque liste énumérative donne lieu à un titrage :

<hn>Titre 1</hn>
<ul>

</ul>

<hn>Titre 2</hn>
<ul>

</ul>

Laurent Denis a écrit :
Non, là, c'est la démarche inverse: linéariser un tableau HTML dans tous les navigateurs à l'aide de display:block et display:inline; Pas faire un pseudo-tableau avec display:table-cell.

Ah oui tiens, j'y pense rarement. C'est à garder en tête.

Florent V. a écrit :

<p>Save the cheerleader; save the world.</p>

La lecture linéaire de cette phrase suffit à dégager la relation de cause à effet

C'est un exemple très intéressant.
Personnellement, cette phrase ne me dit absolument rien. Il me manque certainement une référence culturelle, mais je ne vois absolument pas ce que cela signifie. Et le seul point-virgule ne me sert pas à deviner une relation de cause à effet. Pour le profane que je suis, cette phrase n'a aucun sens : je ne sais pas l'information qu'elle veut transmettre, et sa structure (la relation cause-effet) m'en complètement invisible.
Si, en suivant ton exemple, tu la balises comme ça

a écrit :

<table>
	<tr><th>Cause</th><th>Effet</th></tr>
	<tr><td>Save the cheerleader</td><td>Save the world</td></tr>
</table>

...je ne suis certes pas plus avancé au niveau du sens total (il me manque toujours une référence culturelle), mais je sais au moins de quelle manière je dois lire cette suite de mots : "sauver la cheerleader entraine le sauvetage du monde", et non pas, par exemple, "sauver la cheerleader PUIS sauver le monde" (une sorte de to-do list de super héros... ).
C'est bien sûr un exemple extrême, on ne va pas, comme dit dans un autre thread il n'y a pas si longtemps, baliser au niveau des éléments de phrase (en encore moins avec <table> ici) mais je pense qu'il explique assez bien l'utilité de "sémantiser"

Christian Le Bouler a écrit :
je trouve aussi la liste <ul> est très bien

Le problème de la <ul> est qu'on a une structure (caractéristique:valeur) qui, bien que redondante dans le document, n'est pas balisée. Outre le fait qu'il n'y a pas d'information sémantique sur cette structure, un parseur (Javascript, XML, etc.) ne pourra pas cibler/récupérer facilement tous les livres du type manga, par exemple ; et pour styler les noms des caractéristiques (ou les valeurs), c'est raté aussi. Alors, quitte à rajouter des <span class="">, autant opter directement pour le tableau (ce n'est que mon opinion, bien sûr )
Modifié par marcv (25 Jun 2007 - 11:37)

marcv a écrit :

C'est bien sûr un exemple extrême, on ne va pas, comme dit dans un autre thread il n'y a pas si longtemps, baliser au niveau des éléments de phrase (en encore moins avec <table> ici) mais je pense qu'il explique assez bien l'utilité de "sémantiser"

Il illustre surtout les limites du HTML dans ce domaine. sémantiser (affreux mot), c'est, au-delà de la vague acception générale de ce terme, expliciter, caractériser, pouvoir manipuler une relation. Ici, la relation est purement formelle (X a une relation avec Y).

marcv a écrit :

Le problème de la <ul> est qu'on a une structure (caractéristique:valeur) qui, bien que redondante dans le document, n'est pas balisée.

Au-delà de traitements élémentaires auxquels un span (ou autre) répond, tels que les besoins de présentation, HTML n'a pas cette capacité.

Bref, pour revenir au sujet de départ: la meilleur facon d'un point de vu sémantique de présenter une liste énumérative du type... n'a pas de réponse en HTML (et donc XHTML actuel). C'est là où des démarches telles de l'accessibilité (voire l'ergonomie et le graphisme) jouent leur rôle, même si c'est inattendu ou frustrant
Modifié par Laurent Denis (25 Jun 2007 - 11:42)

Je pense qu'en HTML, un tableau a deux colonnes remplit parfaitement cette fonction de baliser une relation caractéristique:valeur, non ?

marcv a écrit :
un parseur (Javascript, XML, etc.) ne pourra pas cibler/récupérer facilement tous les livres du type manga, par exemple

Désolé je ne sais pas ce qu'est un parseur.

Mais bon les choses sont elles plus facilement récupérables avec un tableau.

Après tout on pourrait pousser la logique du titrage html un peu plus et avoir :

<hn>Titre 1</hn>

<hn+1>Categorie</hn+1>
<p>Livre</p>
<hn+1>Type</hn+1>
<p>Manga</p>

Cela pourait être utile par rapport à des fonctionnalités telles que des plans de document.

Mais même dans ce cas on ne fait que descendre dans l'ordre de la généralité, et je ne vois pas trop ni comment remonter du plus particulier au plus général, ni comment créer des relations qui sont plus de l'ordre des bases de données si j'ai bien compris.

Parce que s'il s'agit de transformer une base de données avec toutes ses potentialités en document html alors là j'ai du mal à suivre je dois dire.

PeterPetrelli a écrit :
je pensais au <dl>

+1

marcv a écrit :
Personnellement, cette phrase ne me dit absolument rien. Il me manque certainement une référence culturelle, mais je ne vois absolument pas ce que cela signifie.

Il y a effectivement une référence culturelle, clin d'oeil à notre ami PeterPetrelli.
Ceci dit, la syntaxe et la connaissance de la langue anglaise permettent de comprendre (pour un humain) la relation de cause à effet.

J'aurais sans doute dû prendre un exemple en français, pour ne pas brouiller les pistes.

marcv a écrit :
Le problème de la <ul> est qu'on a une structure (caractéristique:valeur) qui, bien que redondante dans le document, n'est pas balisée.

La question est alors : pour qui ou quoi (machine) y a-t-il un intérêt à baliser cette structure ?

Tu donnes deux éléments de réponse :

marcv a écrit :
un parseur (Javascript, XML, etc.) ne pourra pas cibler/récupérer facilement tous les livres du type manga

En gros, il s'agit d'adopter un format. Mais si on doit rester avec du HTML4/XHTML1, on se retrouve bien sûr très limité. En gros, soit tu adopteras un microformat pour l'utiliser toi-même (avec le parseur que tu développes) tout en laissant la possibilité aux outils implémentant ce microformat de comprendre tes informations, soit tu fais un format maison, arbitraire.

marcv a écrit :
et pour styler les noms des caractéristiques (ou les valeurs), c'est raté aussi.

Là, ça n'est plus une question de sémantique (mais d'ergonomie, oui).

marcv a écrit :
quitte à rajouter des <span class="">, autant opter directement pour le tableau

Ou bien pour des <span class="">.
Là encore, ça n'est pas la question de la sémantique qui permettra de trancher (pas qu'il faille particulièrement trancher, d'ailleurs).

Donc oui, pourquoi pas un tableau. Ou pourquoi pas des p+span.

J'émettrais par contre une petite réserve sur les listes de définition. Sans aller jusqu'à les proscrire...
Une petite lecture :
http://rgaa.planete-accessibilite.com/discussion/15/1/point-de-controle-36-listes-de-definition

Florent V. a écrit :
Une petite lecture :
http://rgaa.planete-accessibilite.com/discussion/15/1/point-de-controle-36-listes-de-definition

Merci pour ce lien, discussion très intéressante (j'adhère par ailleurs tout à fait à la position de Thierry).

Non, c'est une discussion assez stérile, en fait.

Les listes de définitions souffrent d'abord d'être de ces éléments HTML à la définition trop approximative pour être exploitable. Et ensuite d'avoir été remises à la mode sans trop de réflexion.

Bilan, on aboutit à des abberrations telles que leur emploi pour structurer des formulaires. Et le problème précis auquel on est confronté aujourd'hui est qu'il est impossible de délimiter leur champ de manière à éviter ce genre d'erreur sans être extrêmement restrictif. En sachant que même cette solution restrictive est un pis-aller, l'application à la démarche de définition stricto sensu restant elle-même boîteuse. Mais au moins est-elle inoffensive et a-t-elle une ou deux applications concrètes.

Raison pour laquelle je suis pour ma part aussi réticent quant à l'élargissement du point concerné du RGAA: s'il n'était pas nécessaire d'éviter le grand tout et n'importe quoi des listes de définition, qui a des conséquences immédiates sur l'accessibilité, il n'y aurait pas plus à en parler qu'on ne mentione les var, dfn et autres samp.

(le premier qui me dit pourquoi c'est aberrant dans un formulaire dans l'utilisation classique dt-label et dd-input a évidemment gagné un sucre d'orge )
Modifié par Laurent Denis (25 Jun 2007 - 16:48)

Et bien ...

Merci à tous de votre participation.

J'étais venu ici pour "essayer" de trancher sur les options qui me semblaient adaptées , mais je me rend compte qu'il n'y a pas vraiment de solution plus adapté l'une par rapport à l'autre.

C'est bien la limite du (x)html qui n'est pas là pour organiser des données à proprement parlé.

Pour ma part je n'opterais pas pour un tableau, trop restrictif en terme de mise en page pour ce cas précis.

Je vais donc rester sur mon truc de départ

<ul class="attributs">
  <li><span class="dataTitle">xxx</span>data</li>
...

qui est en fait ce qui ce rapproche le plus d'une representation xml de ce type de données

<attributs>
 <attribut name="categorie">valeur attribut</attribut>
 <attribut name="type">valeur attribut</attribut>
 ....
ou 
 <categorie>valeur attribut</categorie>
 <type>valeur attribut</type>
etc ..

en tout cas merci à vous, pour ces points vu intéressants.

Laurent Denis a écrit :
Non, c'est une discussion assez stérile, en fait.

Je trouve aussi. J'indiquais juste la question sur le forum plutôt que le point de contrôle du RGAA correspondant pour ne pas occulter le fait qu'il y a discussion.

Laurent Denis a écrit :
(le premier qui me dit pourquoi c'est aberrant dans un formulaire dans l'utilisation classique dt-label et dd-input a évidemment gagné un sucre d'orge )

Je suis pas fan du sucre d'orge, mais on peut toujours tenter :
- parce que c'est le label qualifie le input tandis que le dd qualifie le dt ?
- parce que la conséquence de l'utilisation abusive de dt/dd peut être l'omission des attributs id et for qui vont bien ?

Florent V. a écrit :

- parce que c'est le label qualifie le input tandis que le dd qualifie le dt ?

J'ai toujours adoré, en effet, cette approche sémantique qui sait pourtant bien que A décrit B, mais qui place A et B dans des éléments qui disent exactement l'inverse

<edit>Rouge ou vert, le sucre d'orge ? </>
Modifié par Laurent Denis (25 Jun 2007 - 17:50)