Tableau ou pas tableau ?

[DidierK]

Bonjour,

Je présente sur mon site des livres, une page pour chaque livre (exemple).

Dans chaque page, une "fiche" présente toujours le même type d'information : titre, auteur, éditeur, nombre de pages, ISBN,...

Ces fiches ont une structure de tableau.

La question que je me pose est de savoir si le tableau est en fait le plus adapté. Les tableaux sont faits pour présenter des données tabulaires, or ce n'est pas vraiment le cas...

Quelle serait l'alternative sémantique ? Une liste de définition (dl dt dd) ? Serait-elle plus accessible ?

C'est clair que c'est un peu du coupage en 4 de poils de ... de mouche

[Sarc]

Bonjour,

J'ai cliqué sur ton exemple avant de lire la totalité de ton message, et j'ai pensé à une liste de définition en voyant la structure... Je vois que tu as eu la même idée, c'est donc qu'elle est partagée au moins par deux personnes

Donc je confirme mon idée, liste de définition, avec un float:left sur les dt, un width sur ces mêmes dt, pour que tout soit aligné, et ça serait parfait !

[captain_torche]

C'est effectivement de la drosophilie assez poussée

En ce qui me concerne, si tu veux garder une construction sémantique logique, il s'agit effectivement d'un tableau à une seule entrée (dans le sens où tu fais correspondre un titre à un élément, et où tu pourrais très bien, avec la même structure, lister plusieurs albums).

Pour avoir une structure plus propre, tu peux toutefois utiliser la balise th (table header) pour tes "titres", et remplacer ainsi ta structure avec tes classes "left" et "right".

[Sarc]

On peut voir ça comme un tableau à une seule entrée, mais je ne suis pas totalement d'accord avec son utilisation : pour moi dans un tableau, les entrées comportent un type commun...

Par exemple considérons un tableau avec en première colonne une fourchette de notes, et en deuxième colonne le nombre d'élèves de la classe qui ont eu une note dans cette fourchette (voire troisième colonne avec pourcentage...).

La colonne de gauche ne comporte que des éléments qui ont exactement le même type, soit "une fouchette de notes"... C'est clairement un tableau, et donc pas du tout une liste de définition.

Pour cet exemple précis d'informations sur un livre, un nombre de pages, un auteur, un titre n'ont aucun rapport entre eux (en termes scientifiques, on pourrait dire ce que ne sont pas des données homogènes, qu'ils n'ont pas la même unité...) : je vois plus en ça une liste de définition.

Le w3c en dit :

Definition lists vary only slightly from other types of lists in that list items consist of two parts: a term and a description. The term is given by the DT element and is restricted to inline content. The description is given with a DD element that contains block-level content.

C'est bien une liste d'informations qu'il donne sur chaque livre, avec chaque information qui n'a pas forcément de liens avec les autres.

Bon, franchement à la limite peu importe, que ça soit tableau ou liste de définition, ça ne choquera personne mais si on doit pousser dans la sémantique, c'est mon avis sur la question

[TheRec]

Bonjour,

Les avis vont différer sur les questions que tu poses, c'est certain. C'est le même problème qu'il y a avec les formulaires de savoir si un tableau est l'idéal pour présenter les champs et leur libellé...

Personnellement je ne suis pas "fixé" sur un "oui définitif" ou un "non définitif", l'utilisation sémantique des tableaux doit se limiter à des données dites tabulaires (c'est le cas, chaque cellule du tableau correspond à un en-tête) et si c’est la solution que tu choisi, il faut utiliser tous les moyens à disposition pour faciliter l'accès à aux données du tableau (summary, caption, th, td, scope, etc.).

Si tu optes pour un liste de définitions, ce qui est tout à fait valable également, tu n'auras pas certains avantages du tableau (summary entre autres) et tu perds en flexibilité si tu viens à avoir une colonne supplémentaire par exemple (je n'en vois pas l'utilité dans ton cas, mais qui sait ).

Tu vas me dire que cela ne t'avance pas beaucoup, ce que tu dois retenir de ce que je viens de dire c'est que les deux structure son sémantiquement correcte pour les données que tu veux présenter. D'autres te diront certainement de laisser tomber les tableaux pour faire tu 100% tableless et si j'étais toi je ferais la sourde oreille, car selon le W3C n’a jamais recommandé ceci, il recommandent uniquement d’utiliser les élément selon la sémantique

Choisis la solution qui te sembles la plus facile à mettre en œuvre étant donné des deux solutions sont équivalentes dans ton cas.

**EDIT** : Comme prévu lorsque j'ai intiailement rédigé mon message, le débat s'oriente vers la même issue que ce sujet (Hein sarc... )

[Sarc]

Rah zut, déjà incriminé à l'époque...

C'est à relire ce topic, il y a des choses intéressantes je pense... Même si avec le recul, je comprends pas tout ce que j'ai pu dire à l'époque ! Le W3c ne me donne pas tort, en tout cas

[TheRec]

Personnellement du moment qu'il y a bien un lien sémantique entre le libellé et les données qui s'y rapportent, la structure utilisée m'importe peu... Le débat se résume à cela à mon avis. Le W3C ne recommandera jamais l'utilisation d'une ou l'autre de ces solutions (d'abord car ce n'est pas leur rôle premier), ils établissent les recommandations à un niveau d'abstraction plus haut que cela. Les recommandations ne sont justement pas toujours précises au niveau où ce situe le problème évoqué ici car il n'y a pas de solution unique (et donc le W3C devrait établir une liste exhaustive de toutes les possibilités ce qui ne serait pas viable).

L'essentiel étant d'être conscient des choix que l'ont fait et des implications qui en découlent, dans ce cas les deux solutions se valent et j'ajouterai que, par expérience personnelle, la solution des tableaux donne peut-être plus de flexibilité au niveau de l'évolutivité et que dans ce cas précis cet avantage ne sert pas vraiment (je ne vois pas comment pourrait évoluer le contenu du tableau dans ce cas précis).

[DidierK]

Merci beaucoup pour vos avis éclairés.

Je vais garder la structure tableau dans l'immédiat et appliquer vos suggestions pour ce qui concerne th.

Perso, je pencherais plutôt pour les listes de définition... mais bon, je viens de terminer la refonte de A à Z de ce site (qui était auparavant entièrement mis en page en tableaux...), je me garde les prises de tête pour comprendre et styler les listes de définition pour plus tard

[kisscool82]

Vous chipotez un peu la non ?

En tout cas une chose est sur, c'est que ton contenu sera plus propre, j'entend moins poluer par tout un tas de balise table, tr et td, en utiliser des dt et un petit peu de css. Le bots n'en seront que plus content

[captain_torche]

C'est effectivement du chipotage.

Par contre, je ne comprends pas ta position sur la "propreté du code" : un code n'est pas plus propre s'il est tableless.

Un code propre, c'est un code lisible, et compréhensible. L'utilisation de tableaux n'y est pas prohibée, mais réservée à la présentation de données tabulaires.

[maximettb]

Et puisqu'on est dans la partie ergonomie, pourquoi ne pas mettre les descriptions en avant, et non les caractéristiques du livre. Après tout, la description de l'ouvrage est tout de même bien plus important que ses dimensions !

[Lanza]

+1 comme on dit.

Sinon pour la problématique de la fiche, pas de dl, dt, dd.

"1974" n'est pas la définition de "Date d'édition". Ce serait même plutôt l'inverse.

Modifié 27 Juin 2007 par captain_torche
Inutile de citer le message précédent; on vient de le lire (captain_torche, modérateur)

[DidierK]

Et puisqu'on est dans la partie ergonomie, pourquoi ne pas mettre les descriptions en avant, et non les caractéristiques du livre. Après tout, la description de l'ouvrage est tout de même bien plus important que ses dimensions !

Pas si simple... Importante pour qui ? Pour les collectionneurs, archivistes, bibliothécaires,..., les dimensions, dates, changements d'ISBN,..., valent plus que le contenu !

[killian]

L'avantage des listes de définition par rapport aux tableaux dans ces cas là est que le code n'est pas plus propre, mais plus léger.

Or un code plus léger signifie moins d'octets pris par la structure, et donc un pourcentage de données plus grand pour le contenu en lui même du site. Ce n'est pas grand chose, mais pour un robot qui analyse votre site je pense que ça peut valoir le coup.

Les tableaux sont cependant très efficaces dans certains cas, il ne faut pas les abandonner pour autant

[Dudu]

Salut

pour un robot qui analyse votre site je pense que ça peut valoir le coup.

Je pense très exactement l'inverse puisque la notion de sémantique trouve tout son intérêt dans la lecture du code par des robots, qui vont y trouver une sorte de contexte à un contenu donné.

Pour les humains utilisant un écran, la sémantique n'est d'aucune utilité: elle ne se voit pas.

Donc utiliser une liste de définition plutôt qu'un tableau pour présenter des données tabulaires: non.

Et utiliser les listes de définition parce que ça fait plus classe que des tableaux: c'est ridicule.

Quant à utiliser un code soi-disant plus léger mais dont la sémantique est nulle: quel intérêt ?!??

Ce qui importe, c'est la sémantique. Tableau ou pas tableau.

[killian]

Je suis désolé mais j'ai bien l'impression que dans ce cas précis, les tableaux ne soient pas la bonne solution. Ce ne sont pas des statistiques, pas des données que j'estime devoir être présentées dans un tableau.

Cela ressemble plutôt à un mot et à sa définition, donc oui je pense que les listes de définitions sont les plus adaptées, que ce soit au niveau de la sémantique ou au niveau de la lourdeur du code.

Je n'ai jamais dit qu'il ne fallait pas respecter la sémantique pour les robots, mais ce n'est pas un secret non plus que la taille des documents compte dans le référencement !

[Dudu]

Cela ressemble plutôt à un mot et à sa définition, donc oui je pense que les listes de définitions sont les plus adaptées [...] au niveau de la sémantique.

Chacun verra midi à sa porte, mais dans l'absolu je ne considère pas "24cm x 18,5cm" comme étant la définition du substantif "dimensions".

Mon dictionnaire le confirme, par ailleurs.

Le fameux article de Maxdesign sur les listes de définitions (traduit par Pompage) a créé un effet de mode hélas dévastateur d'un point de vue sémantique.

J'ai l'impression que depuis la publication de cet article, tout le monde veut utiliser les listes de définitions à tout prix

Je n'ai jamais dit qu'il ne fallait pas respecter la sémantique pour les robots, mais ce n'est pas un secret non plus que la taille des documents compte dans le référencement !

Fort heureusement, le mot "robot" ne rime pas nécessairement avec le mot "référencement". D'ailleurs, il me semble que cette discussion se trouve dans la section destinée à l'accessibilité et non celle destinée au référencement

Dans un cadre d'accesibilité et d'ergonomie, les robots qui nous intéressent sont plutôt les parseurs destinés aux synthèses vocales, par exemple

[Sarc]

Avec un peu de recul sur cette discussion, je suis moins catégorique qu'à l'époque... Décidément, je me montre bien lunatique dans la gestion de mon code !

En fait, cette structure n'est ni tabulaire, ni une liste de définition. C'est une liste de caractéristiques, mais la balise "Liste de caractéristiques" n'ayant pas été inventée, il faut la remplacer par quelque chose d'autre.

Et en fait, que ça soit tabulaire, ou liste de définition, je pense que les deux sont fausses sémantiquements, donc discutables dans leurs utilisations. Donc on peut utiliser une des deux, au choix

La définition que j'ai trouvée de tableau ne m'avance guère :

B. 1. Série d'informations, de données disposées de façon claire et systématique et permettant une consultation rapide et globale.

J'avoue ne pas être certain de ce qu'il veut dire par "systématique".

Quand j'ai écrit les premiers posts ici, je me disais que dans un tableau, on devait avoir une cohérence spatiale dans un tableau : par exemple, tous les éléments d'une même colonne devrait avoir une même "dimension", représenter la même chose. En physique, on fait une colonne pour le temps, une pour la distance par exemple... Dans cet exemple précis, on n'a pas cette cohérence, d'où mon choix à l'époque de la liste de définitions.

Maintenant, en lisant la définition d'un tableau, je suis plus perdu.

Dudu, à l'aide !

[captain_torche]

Personnellement, je considère un tableau comme un format permettant de mettre en relation des données, verticalement et horizontalement.

Comme ce que cherchait à faire DidierK me semble convenir à cette utilisation (mis à part qu'on n'aurait qu'une seule entrée horizontale), je continue à penser que le tableau serait la meilleure solution.

[Sarc]

Oui mais les données en vertical n'ont aucune relations entre elles, sinon le fait qu'elles soient des caractéristiques des bouquins... C'est ça qui me dérange, c'est qu'on ne peut pas relier entre elles les lignes du tableau, elles sont toutes différentes ! Pour revenir à mon exemple de tableau DISTANCE-TEMPS, toutes les données de la première colonne sont des Distances, et la donnée juste à leur droite est le temps qu'on associe à la distance.

Là, la première colonne n'a pas de ligne directrice. C'est ce qui me gênait dans la définition du tableau

[Monique]

Bonjour,

Maintenant, en lisant la définition d'un tableau, je suis plus perdu.

Même si je ne suis pas certaine que cela t'aidera à te retrouver, je pense que tu seras intéressé par la lecture de cette discussion sur le forum RGAA (Référentiel Général d'Accessibilité des Administrations).

[captain_torche]

Oui mais les données en vertical n'ont aucune relations entre elles, sinon le fait qu'elles soient des caractéristiques des bouquins...

Il n'est pas nécessaire qu'elles aient des relations entre elles (quoi que là, elles sont tout de même pas mal liées). L'essentiel selon moi, étant qu'elles permettent une comparaison dans le cas où on aurait plusieurs livres listés.

[kisscool82]

C'est effectivement du chipotage.

Par contre, je ne comprends pas ta position sur la "propreté du code" : un code n'est pas plus propre s'il est tableless.

Un code propre, c'est un code lisible, et compréhensible. L'utilisation de tableaux n'y est pas prohibée, mais réservée à la présentation de données tabulaires.

J'entendais simplement qu'une mise en page sans tableau = moins de balises, donc code plus propre car contenu moins dilué, et donc page plus réactive

[Dudu]

moins de balises, donc code plus propre car contenu moins dilué, et donc page plus réactive

Et puis la sémantique on s'en fout parce que la page est plus réactive ?

J'aimerais avoir ton avis là-dessus.

Sinon, pour avoir le moins possible de balises, on n'a quà toutes les enlever: le contenu sera moins dilué, il y aura moins de balises.

Pour autant, est-ce que le contenu sera plus propre et la page plus réctive ?

[Monique]

Bonjour,

moins de balises, donc code plus propre car contenu moins dilué, et donc page plus réactive

Un code propre, c'est un code qui

- structure correctement le contenu

- utilise les balises adéquates

- utilise les balises nécessaires, et seulement celles-la.

Exemple

<p>item 1<br />
item 2<br />
item 3</p>

<ul>
<li>item 1</li>
<li>item 2</li>
<li<item 3</li>
</ul>

Il y a certes moins de balises dans la première liste, mais laquelle sera la plus réactive, la plus utile aux utilisateurs d'aides techniques... ?

Si, en plus, le code est correctement indenté, sa lecture et sa maintenance en seront facilitée.

Et tout cela n'a rien à voir avec le nombre de balises