A table !

Tableau ou pas Tableau ? De la bonne utilisation des tableaux et de la balise TABLE

Bien que la grande majorité des sites web soient encore construits actuellement grâce à l'utilisation de tableaux, la balise TABLE est conçue initialement pour afficher des données... tabulaires (un calendrier, une base de donnée, des statistiques par exemple) et non pour faire la présentation de sa page. Ce n'est plus un scoop.

Comme tout le monde, vous connaissez les articles décrivant les différents problèmes que posent les tableaux : OpenWeb [fr] et Cybercodeur [fr]

Je ne vais pas revenir là-dessus : les tableaux ne sont pas fait pour la mise en page et il faut pour cela utiliser des alternatives fondées sur le couple DIV / CSS.

Note : pour information, le W3C n'interdit pas l'utilisation des tableaux pour la mise en page. Rien n'empêche un site présenté en tableaux d'être Valide en XHTML Strict.

Il permet même des constructions complexes destinées en théorie aux données tabulaires :

The HTML table model allows authors to arrange data -- text, preformatted text, images, links, forms, form fields, other tables, etc. -- into rows and columns of cells.

Par contre, le W3C déconseille lui-aussi l'utilisation de tables pour les mises en pages, mais sans pour autant proposer de solutions concrête :

Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables.

De la bonne utilisation des tableaux

Pour ne pas verser (comme certains) dans un fanatisme anti-tableaux, je me posais simplement et candidement la question inverse : quand peut-on utiliser les tableaux sur son site web ?

Les extrêmistes auront tendance à répondre catégoriquement, mais je suis persuadé que la réalité est bien plus nuancée.

Pour commencer, le principal argument anti-tableau (outre sa lourdeur) est sa non-Accessibilité aux handicaps et notamment aux non-voyants. En effet, ces personnes ont des difficultés à se faire une "vue d'ensemble" d'un design construit sous forme de tableaux.

Ce problème est bien évidemment accentué en cas de tableaux imbriqués, de rowspan, colspan et autres spacer.gif traînant dans le code.

Mais... un tableau n'est pas obligatoirement lourd, imbriqué et inaccessible. Il existe des moyens pour rendre un tableau tout à fait accessible et propre. En mettant ces moyens en place, doit-on encore systématiquement sataniser les tableaux ? Peut-être que oui, peut-être que non (j'avoue que je ne me mouille pas trop sur cette question !).

En fait, la question ne se poserait pas s'il n'existait pas actuellement des limites aux alternatives en DIV... mais malheureusement ces limites (peu nombreuses) existent.

Limites actuelles des alternatives en DIV...

N'étant pas particulièrement spécialiste de ce sujet, j'ai néanmoins compté plusieurs cas dans lesquels la mise en page en DIV pose de sérieux problèmes sans bidouilles ou hacks : le problème de "l'espace vertical restant", celui de l'alignement vertical et celui de colonnes à hauteurs égales (merci à Etienne Depaulis de me l'avoir rappelé)

Ces deux problèmes reviennent régulièrement dans les forums de discussion web que je fréquente.

Problème de "l'espace vertical restant"

schema1 schema2

Considérez une mise en page composée de deux blocs. Le premier bloc, au-dessus, a une hauteur fixée en pixels, pourcentage ou em. Le second bloc, en-dessous, doit occuper le restant de la page quelle que soit la résolution et même si l'utilisateur redimensionne la fenêtre de son navigateur. Ce cas est illustré par le schema 1.

Dans le même ordre d'idée, le schema 2 représente la même mise en page avec l'ajout d'un pied de page qui doit être tout le temps collé en bas de page.

Ces deux constructions sont très classiques et pourtant non réalisables (à ma connaissance) simplement à l'aide de DIV.

Il existe bien entendu des techniques permettant de contourner les problèmes posés, par exemple d'émuler la propriété min-height, mais toutes les techniques relèvent actuellement de la bidouille.

L'alignement vertical

Autre cas d'école : réussir à aligner verticalement un ou plusieurs éléments dans un bloc conteneur dont la hauteur est connue ou non. Là encore, la fonction vertical-align n'est apparemment pas prévue pour ça et en tout cas ne fonctionne pas.

Il existe là aussi des techniques d'alignement vertical en CSS, notamment à l'aide des marges négatives, mais ces techniques montrent rapidement des limites notamment en terme de compatibilité.

Colonnes de hauteurs égales

Avoir deux blocs côte à côte de même hauteur quel que soit le contenu dans les blocs n'est pas chose aisée car un bloc div ne se comporte pas comme une cellule de tableau et ne s'étire pas en fonction de son voisin.

Il existe là encore des méthodes pour s'en sortir et simuler le comportement tabulaire, voir les liens suivants : www.pixy.cz [en], www.pmob.co.uk [en], www.alsacreations.com [fr].

Ces trois exemples de limites aux constructions DIV montrent, s'il en est besoin, qu'aucune technique n'est actuellement dénuée de faiblesses.

Donnée tabulaire ?

Autre piste intéressante à débattre : qu'est-ce qu'une donnée tabulaire? Dans quels cas une donnée nécessite-t-elle une structure tabulaire ?

A force de nous rabâcher qu'une table doit se limiter à des données tabulaires, on en vient presque à oublier ce que ce terme signifie vraiment et ce qu'il désigne. Qu'entend-on par "donnée tabulaire" ? Quelles sont les données qui peuvent être concernées ?

Une donnée tabulaire est une valeur qui s'affiche préférentiellement sous forme de colonnes verticales et de lignes horizontales et d'une correspondance entre les deux. Ceci accepte évidemment un éventail assez large de solutions : un formulaire d'inscription est-il suffisamment "tabulaire" pour entrer dans cette catégorie ? Oui selon les cas, non selon d'autres.

Les spécifications du W3C [en] sont très vagues et ne donnent aucun renseignement quant à la bonne utilisation de tableaux.

Or, selon moi, certains cas concrets ne sont pas toujours très catégoriques. Parfois la question se pose : tableau ou pas tableau ?

Pour ce qui est des calendriers, bases de données et statistiques par exemple, la question ne se pose pas. L'utilisation de tableau est totalement justifiée.

Dans d'autres cas, la réponse est plus nuancée : si les tableaux me semblent être appropriés pour des plannings d'activités et des emplois du temps, qu'en est-il par exemple pour des catalogues de produits avec références et prix ? Des Listes de Définitions ne seraient-elles pas parfois plus appropriées ?

Que dire de tout ce qui touche aux Forums, Livres d'Or ou Blogs ? Sont-ils si éloignés de ce qu'on peut admettre comme donnée tabulaire ?

Et ces fameux Formulaires d'inscription, ou encore les CV en ligne, dans quelle catégorie les classer ? Cela dépend-il de leur complexité ?

Je lance donc un appel aux spécialistes de ce domaine pour m'éclairer et répondre à ces différentes questions : qu'est-ce qu'une donnée tabulaire et quelles données ou structures peuvent être considérées comme tabulaires ?

Certains cas concrets sont parfois plus vagues qu'il n'y paraît au premier abord. Entre les tableaux (TABLE), Listes de Définitions (DL), Listes simples ou imbriquées (UL/LI) ou les blocs neutres (DIV), le choix est parfois cornélien.

Parfois même, la définition du W3C est tellement vague que l'on pourrait d'utiliser l'une ou l'autre balise tout en restant sémantiquement propre.

Alors je dirais simplement : attention aux fanatismes et extrêmismes démesurés car, comme partout, tout est souvent question d'interprêtation et de nuances...

Par Raphael GOETTER - samedi 29 mai 2004 à 21:30

Standards et Accessibilité - #11 - Lu 14874 fois - Intérêt du billet: 2.7(30) - Fil RSS

Trackbacks

Le mercredi 13 octobre 2004 à 13:40, de Stéphane Sulikowski - Webdesigner :: #

L'art de la table

Je le crie donc haut et fort : le n'est pas mort, loin de là. Certes comme cité ci-dessus il est plus judicieux d'utiliser les CSS pour constituer la mise en page, mais des éléments tels qu'un calendrier, une liste de produits, etc...

Le mercredi 13 octobre 2004 à 13:40, de Stéphane Sulikowski - Webdesigner :: #

L'art de la table

Je le crie donc haut et fort : le n'est pas mort, loin de là. Certes comme cité ci-dessus il est plus judicieux d'utiliser les CSS pour constituer la mise en page, mais des éléments tels qu'un calendrier, une liste de produits, etc...

Les trackbacks pour ce billet sont fermés.

Evaluez ce billet

Commentaires

Le samedi 29 mai 2004 à 21:54, par Etienne Depaulis :: site :: #

Salut,

je voulais juste rajouter que les tableaux peuvent être très utile pour faire une mis en page 3 colonnes accessible à tous et à toutes (surtout avec IE)

Le samedi 29 mai 2004 à 22:11, par Raphael Goetter :: site :: #

@Etienne Depaulis > Oui tu as raison : j'avais oublié un autre problème des divs, celui des colonnes étirables.

Le dimanche 30 mai 2004 à 01:37, par mauriz :: site :: #

Rien n'empêche de mixer les différentes méthodes: le positionne global avec un tableau léger de 3 cellules, des éléments positionnés ) l'intérieur avec des CSS, etc.
En production, les tableaux peuvent faire gagner un peu de temps: tout est histoire de compromis.

Le dimanche 30 mai 2004 à 09:00, par Etienne Depaulis :: site :: #

Je confirme ce que dit mauriz, c'est d'ailleurs la technique que j'utilise actuellement pour un gros site :
- j'ai un seul tableau avec 3 cellules, le tout ayant des attributs CSS en pourcentages et à l'intérieur des cellules des blocks de taille fixe

Au départ j'avais commencé avec des position: absolute et des float mais je me suis toujours retrouvé avec des résultats bien différents dans chaque navigateur, je suis donc passé au tableau et le résultat est le suivant :
- moins de prise de tête
- 12 caractère en plus pour la structure

Le dimanche 30 mai 2004 à 10:19, par Antoine :: site :: #

Alala, l'éternel problème des tableaux, pas mal ton article sib.
En tout cas, tout est question de spécificité, aucune réponse ne mettra tout le monde d'accord.
Tu n'as pas parlé des titres de tableaux qui sont indispensable à la validation (<th>)

ps: j'ai une blème avec ton textarea ici, à chaque fois que je clique dessus, il s'agrandit, et je perd le curseur à droite. Je ne sais donc ni descendre, ni monter.

Le dimanche 30 mai 2004 à 10:25, par Raphael Goetter :: site :: #

@Antoine >
- Pour les <th>, j'évoque les moyens pour rendre un tableau tout à fait accessible et propre : openweb.eu.org/articles/t... Vu qu'il y'a tout ce qu'il faut sur ce lien, je me suis dit qu'il n'était pas utile de le paraphraser.
- Pour le problème de textarea c'est curieux en effet. Je n'ai (presque) rien modifié aux CSS des zones de commentaires et j'ai testé sur un certain nombre de configurations.
Quelle est la tienne ?

Le dimanche 30 mai 2004 à 10:54, par Etienne Depaulis :: site :: #

Est-on obliger d'utiliser des <th> si l'on a seulement un tableau de données sans titres ?

Le dimanche 30 mai 2004 à 10:58, par Raphael Goetter :: site :: #

Non, ce n'est pas obligatoire dans le sens où le code suivant passe le Validateur :
<table>
<tr>
<td></td>
</tr>
</table>

Le dimanche 30 mai 2004 à 13:43, par Etienne Depaulis :: site :: #

ça marche merci beaucoup

Le dimanche 30 mai 2004 à 16:03, par Bobe :: #

"pour information, ce n'est pas le W3C qui désapprouve les tableaux." [pour faire de la mise en page?]

Euh si, c'est indiqué très clairement au premier chapitre de la section sur les tables de la recommandation HTML 4.01. Le w3c déconseille leur utilisation pour la mise en page. (Il y a également une très courte note dans la recommandation sur HTML 3.2).

Bon, sinon, ça me parait limpide. Théoriquement parlant, les tableaux doivent être utilisés pour des données tabulaires et rien d'autre. CSS2 a tout ce qu'il faut pour simuler la présentation en colonnes.

(Notez le "théoriquement". Je ne m'attarde pas sur le cas pratique)

Le dimanche 30 mai 2004 à 17:10, par Raphael Goetter :: site :: #

@Bobe >
"Euh si, c'est indiqué très clairement au premier chapitre de la section sur les tables de la recommandation HTML 4.01."
>>> Tiens, je dois avoir de mauvaises sources du W3. Dans mes recherches, je n'ai trouvé que ce lien qui ne dit rien de spécial : www.w3.org/TR/REC-html40/...
Par contre, j'ai trouvé une traduction de La Grange qui indiquait que l'utilisation des tableaux étaient déconseillés pour la mise en page... mais je n'ai rien trouvé sur le site original.
Je vais éditer le billet pour préciser ma pensée

"Théoriquement parlant, les tableaux doivent être utilisés pour des données tabulaires et rien d'autre."
>>> Euh, oui, aucun doute là-dessus ;)
L'idée générale du billet est justement de définir exactement ce qu'est une Donnée Tabulaire et ce qui en fait partie ou non.

Le dimanche 30 mai 2004 à 23:16, par Bobe :: #

"Tiens, je dois avoir de mauvaises sources du W3. Dans mes recherches, je n'ai trouvé que ce lien..."

Bah il dit ça, quand même ;-):

"Tables should not be used purely as a means to layout document content as this may present problems when rendering to non-visual media. Additionally, when used with graphics, these tables may force users to scroll horizontally to view a table designed on a system with a larger display. To minimize these problems, authors should use style sheets to control layout rather than tables."

Le dimanche 30 mai 2004 à 23:37, par Raphael Goetter :: site :: #

@Bobe > oui, comme écrit précédemment, j'ai modifié et clarifié cette partie dans le billet ;)

Le lundi 31 mai 2004 à 15:36, par Antoine :: site :: #

Hello,
IE6 - Win2K

Le mardi 1 juin 2004 à 19:03, par Gizmo :: #

Well, well, well.

Ce qui m'embête un peu dans cette article, c'est que dans sa première lecture, un néophite pourrait croire que tous ces problèmes sont dûs aux limitations des DIV et CSS. Hors il n'en n'est rien.
Le véritable problème provient plutôt du non respect par les différents navigateurs ou de la mauvaise interprétation de ses normes.

Tout d'abord, un petit avertissement aux troll éventuels qui rétorqueraient que ce ne sont que des "recommendations". A ceux-ci je répondrai de lire plus attentivement les quelque lignes d'introduction au différents documents du W3C qui sont "W3C produces what are known as "Recommendations". These are specifications, developed by W3C working groups, and then reviewed by Members of the Consortium. A W3C Recommendation indicates that consensus has been reached among the Consortium Members that a specification is appropriate for widespread use." Il s'agit donc bien de spécifications que les différents acteurs qui y ont participé se sont engagés à respecter. Ceci inclus les différents "fabricants" de navigateurs.

Maintenant, reprenons les différents problèmes et examinons leur résolution théorique:

- Pour tout ce qui est gestion des hauteurs, le CSS dispose d'une série de mode de display destinés à reproduire que que les webdesigners appréciaient dans la mise en forme par tableau. Ces modes de display ont même pris des nom qui évoque le fonctionnement des tableaux (table, table-cell, ...). Avec ceux-ci, il est très facile d'obtenir les effets voulus, tant pour le positionnement des blocs que pour le positionnement au sein des blocs.

- Le centrage sur la page d'un bloc, pour lequel Sib propose d'utiliser des marges négatives devrait, lui, se résoudre avec un positionnement fixe car directement lié à la surface affichable de l'écran.

- Pour les formulaires, on a souvent tendance à les considérer comme des données tabulaires parce que l'on met en correspondance l'input et son intitulé. Hors, cet intitulé devrait se mettre sous forme de label et donc englober son input, ce qui réduit à néant la théorie d'utilisation des tableaux

- Calendriers, statistiques, BDD, Planing, pas de commentaire, la structure même d'une BDD, d'un agenda et des données statistique étant tabulaire, pas de raison d'en changer le sens... où alors on se rapproche d'une démarche artistique mais qui ne justifie plus une lecture linéaire de l'information.

- Pour les listes de prix, les listes de définitions ne seraient pas des plus appropriées. En effet, un prix ne défini pas un article, il le caractérise. Par contre, dans le cadre de la description d'un article, le prix pourrait être l'un des arguments s'insérant dans une liste de définition, comme on peut le voir sur l'exemple du W3C (www.w3.org/TR/html4/struc...

- Pour tout ce qui est forum, blog, livre d'or, il n'y a pas de réponse catégorique. En effet, les données qui les composent devraient plutôt être formatée en XML, celui-ci permettant de mieux définir le rôle de chaque objet. Du coup, le choix doit se faire en fonction du sens de la lecture que veut donner le webmaster à ses lecteurs.


Maintenant regardons le côté pratique. AUCUN des browsers actuels ne respecte 100% des spécifications HTML/CSS. De gros efforts sont fait chez certains et il faut les applaudir et les encourager (en utilisant les possibilités qu'ils nous offrent ?) Le gros problème provient du leader qui n'a plus fait de mise à jour de son moteur de rendu depuis plus de 2 ans et qui semble de pas vouloir changer d'avis avant fin 2006.

Alors que faire? Certains détestent les hacks, prétextant qu'un site ne doit pas être façonné pour un browser, mais de manière uniforme pour tous.
Je ne suis pas de cet avis et j'ai choisi de parier sur l'avenir. Dans mes nouveaux sites, j'utilise donc des hacks, mais je les utilisent en pariant sur l'avenir. Je m'explique. Je réalise ces sites sans me soucier de IE, trop restricitif, et de NS 4.7 obsolète et facilement remplaçable même sur des vielles machines. Ensuite, quand cela est fait, je regarde le résultat sur IE. Généralement, le résultat n'est pas *TROP* catastrophique. Quand j'ai déterminé ce qui pose problème (avec l'habitude, ça va très vite), plutôt que de faire des contorsions dans le code et jouer de malice en utilisant des caractères absconds (cf Tantek hacks & co), j'isole ces parties de CSS, je les marque comme important (règle css très pratique) et je les place dans un fichier que j'appelle avec un import, mais en utilisant une syntaxe que IE est incapable d'interpréter. Ainsi, je peux, dans le code "classique" des CSS, utiliser des fonctionnalité simplifiées pour IE tout en gardant les fonctionnalités étendues pour les autres browsers. Ainsi, je prends le paris que le jour (que j'attend avec impatience) où IE saura interpréter mon import correctement, c'est que celui-ci aura modifié son moteur de rendu et sera à même d'utiliser les fonctionnalités étendues (si on n'est pas déjà aux CSS3 et XHTML2 :o ).

Bien sûr, ce n'est que mon avis et les propos tenus dans ce post n'engage que moi et bla bla bla...

Note pour plus tard: rajouter ce blog sur ma liste à visiter de temps en temps ;)

Le mardi 1 juin 2004 à 19:05, par Gizmo :: #

Re-note pour plus tard: pour corriger son orthographe, se relire, se relire, toujours se relire... :(

Le mardi 1 juin 2004 à 19:51, par davux :: site :: #

www.moronicbajebus.com/pl...
Je dirais que cet article donne une très bonne idée de ce qu'on peut attendre d'un tableau, et prend le problème dans l'autre sens: on peut avoir des données "sémantiquement tabulaires", mais ne pas vouloir les afficher en grille.

Au vu de cet article, je dirais que des données tabulaires, ce sont des données classifiables par catégories, c'est-à-dire qu'on *pourrait* mettre dans un tableau dans lequel chaque tableau représente une catégorie (comme Nom, Image, Auteur, etc.).

Le mardi 1 juin 2004 à 22:53, par Raphael Goetter :: site :: #

@Gizmo > merci pour ton commentaire intéressant et argumenté.
Pour ce qui est de ton avis sur le centrage et de la gestion des hauteurs, tu as beau dire que le CSS dispose d'une série de mode de display etc... mais en attendant (comme tu le rajoutes), ces propriétés ne sont pas appliquées partout.
Bref, on est obligé d'utiliser des hacks, des bidouilles pour compenser, ce que je refuse de faire.
En comparaison, les tableaux n'ont pas besoin de ces bidouilles pour ces cas précis, donc il s'agit bien de limites des div/css (ou plutot de limites navigateurs)

@davux > Je n'arrive pas à accéder à ton lien :(

Le mercredi 2 juin 2004 à 10:37, par Bobe :: #

gizmo: "Hors, cet intitulé devrait se mettre sous forme de label et donc englober son input, ce qui réduit à néant la théorie d'utilisation des tableaux"

Il y a un exemple d'utilisation de tableau pour présenter un formulaire dans la recommandation HTML 4.01 (que ce soit correct ou pas, l'exemple est bien présent), et un label n'englobe pas obligatoirement la commande à laquelle il est lié.

"Le gros problème provient du leader qui n'a plus fait de mise à jour de son moteur de rendu depuis plus de 2 ans"

2000-2004, ça fait 4 ans.

Le mercredi 2 juin 2004 à 10:51, par davux :: site :: #

Raphael: je viens de retenter, ça marche très bien: j'ai cliqué à partir du commentaire directement. Je redonne le nom sans les http pour pas avoir de lien automatique, à tout hasard: www.moronicbajebus.com/playground/cssplay/reformat-table/

Le mercredi 2 juin 2004 à 10:55, par Raphael Goetter :: site :: #

@davux > ok pour le lien. Par contre, ce qui me gêne est la fameuse formule : "It works in Mozilla 1.4+ and Opera 7.0. It does not work in Windows Internet Explorer 6."... L'Accessibilité, c'est bien que le site fonctionne partout et pour tout le monde, non ? :-/

Le mercredi 2 juin 2004 à 11:52, par Gizmo :: #

Pas tout à fait. On confond souvent Accessibilité avec Apparence. L'accessibilité c'est le faite de pouvoir consulter le site sans être handicapé par son balisage. Dans l'exemple de Davux, la table s'affichera de manière classique sur IE, sans fioriture. Elle sera donc tout autant accessible, mais son apparence sera différente.

Le lundi 7 juin 2004 à 23:38, par ginto :: #

Je novice.. et débarque... mais alors en vous lisant, comment présenter une série de 12 à 16 photos (121"134) en quinquonce dans une grille de 4 col 5 lignes sans que les cellules s'agrandissent ? table or not table ? et avec du texte dans 2 cellules mergées.

Le mardi 8 juin 2004 à 09:20, par Raphael Goetter :: site :: #

@ginto > Personnellement, je placerais les images en flottant (avec des marges pour gérer ton quinconce)

Le samedi 17 juillet 2004 à 10:44, par Anthony :: site :: #

@Raphael> le problème avec les blocs flottants sous IE, c'est que lorsque qu'on y applique une marge, ben la marge est doublé ( bug de IE surement ), et aussi le problème du 3px insécable... sacré Billou :D

et le hack à la <div class="spacer">&nbsp;</div> obligé d'utilisé par IE n'intègre pas le :after

je m'explique :

<style type="text/css">
<!--
div:after { clear: both }
.spacer { clear: both; font-size: 1px; line-height: 0px }
// -->
</style>

<div>mettre ici des objets en float</div>

c'est carrément plus simple que de faire :

<div>
les floats
<div class="spacer">&nbsp;</div>
</div>

faut vraiment que Crosoft fasse un effort de ce coté là :D

Le lundi 19 juillet 2004 à 10:09, par Laurent Denis :: #

@Anthony : ce serait en effet une solution très élégante :)
(Mais avec en plus une règle content: "\00A0"; pour que ça marche ;) )

Le jeudi 29 juillet 2004 à 11:21, par fx :: site :: #

Si qqun pouvait m'expliquer la solution pour le probleme de "l'espace vertical restant", pour l'exemple de gauche, je lui serait reconaissant.J'aimerais appliquer cette methode sur mon site.
merci

a+
fx

Le dimanche 8 août 2004 à 11:29, par Anthony :: site :: #

fx> heu je n'ai pas trop compris ta question... tu veux savoir comment faire pour que 2 colonnes ai la même hauteur quelques soit le contenu ?

si c'est ça, y'a bien une solution que tu peux trouver dans le code source de mon site :)

Le dimanche 8 août 2004 à 11:41, par Sibelius :: site :: #

@fx> et si tu cherches un tuto, Alsa n'est pas loin ;-)
www.alsacreations.com/art...
Mais sache qu'il n'y a pas de solution miracle : les div ne sont pas des cellules.

Le vendredi 13 août 2004 à 23:00, par fx :: site :: #

>anthony, dans l'article le probleme est posé, et il est dit qu'on ne peut le resoudre qu'avec de la bidouille, j'aimerais savoir comment.

>sibelius, je t'ai posé la question par email, tu m'avais repondu que malheureusement c'etait impossible ...

Le vendredi 13 août 2004 à 23:06, par fx :: site :: #

>Anthony, pour bien comprendre mon pb, jette un coup d'oeil sur l'ebauche de mon site .
Tu verras en page d'accueil une section avec des 'news' postée. Cette section possede un ascenceur, ce qui est le comportement souhaité. Maintenant redimensionne la fenetre en plus petit, tu verras apparaitre un 2e ascenceur, ce que je ne souhaite pas (ca ne le fait pas en vertical).
J'aimerais que la zone retrecisse jusqu'a la taille du menu environ au minimum, avant de voir eventuellement le 2e ascenceur apparaitre.

merci
fx

Le samedi 14 août 2004 à 09:53, par Raphael Goetter :: site :: #

@fx > Il y'a plusieurs incohérences dans ton document, notamment au niveau de la partie qui te gêne (bloc "page").
- Tu lui donnes une largeur (auto), or un bloc n'a pas besoin de largeur : il occupe toujours toute la largeur restante par défaut.
- Autre point : dans "page", tu as un bloc "article" qui lui-aussi a une largeur (97%), mais 97% de quoi? 97% de auto? ça fait combien ?

Il doit y avoir d'autres petites choses comme ça. Mais sache que si tu fixes une largeur à un bloc, il est normal qu'un ascenseur vertical apparaisse si tu réduis la fenêtre.

Autre chose : à partir du moment où tu mets du contenu dans le bloc, il ne pourra jamais se réduire à une taille nulle comme tu me l'as demandé par mail : il faudra toujours une place pour le contenu !

Le samedi 14 août 2004 à 16:44, par fx :: site :: #

Salut et merci d'avoir repondu
Oui j'ai bien compris qu'il fallait une taille minimale, mais ramener cette taille mini a la taille du menu serait deja suffisant. En fait le but est d'avoir un site visible du 640*480 au 1600*1200 en conservant une occupation maximale de l'ecran.

Le mercredi 20 octobre 2004 à 19:25, par erickk :: #

ouais. je voudrais pas troller, mais nouveau venu dans le CSSP, je trouve qu'on se prend pas mal la tete a mettre nos docs en page des qu'on laisse tomber les tableaux.

Les table, c etait bourre de bugs, mais avec de la methode, on s'en sortait pas trop mal. Quand on design a partir de photoshop/illustrator, c etait pratique surtout avec des outils WYSIWYG genre Dreamweaver avec les retailles de colonnes en clair etc...

Je veux dire qu'on propose maintenant d'oublier les tableaux pour x (bonnes) raisons, mais que pour le remplacer, l'outil est plutôt barbare. Bien sur d'ici 2-4 ans, tout plein d'outils seront adaptés et les navigateurs seront sans doute compatibles, en attendant nous voila revenu au bon vieux temps du html code en dur dans des navigateurs pas compatibles.

Enfin pour clore le chapitre du venerable Netscape 4.7x, oui il faut le garder. Ca depend de votre contenu, si c'est un site sur la StarAc, sans doute MSIE suffit, mais pensez quand meme que le 4.7 reste de base dans plein d OS du monde Unix. Je sais, c est moche ca se fait pas. Mais a croire que vous n'avez jamais affronte un syadmin AIX ou HP pour mettre a jour un navigateur... J'en sais quelque chose, dans mon metier c est bien dans la derniere de mes priorites, la mise a jour du browser.

erickk ki en arrache avec les foutus div et span en regrettant la belle periode des tables ;)

Le mercredi 20 octobre 2004 à 19:31, par Raphael :: site :: #

@ erickk > aah, le vieux débat qui s'annonce ! :)
Je ne vais pas m'y risquer, je te propose simplement de méditer là dessus :
www.alsacreations.com/blo...

Raphael, qui a de la chance de ne pas être non voyant.

Le dimanche 31 octobre 2004 à 10:51, par clb56 :: #

apparemment la réponse à la question concernant la définition des données tabulaires n'a pas été donnée. Je me permet donc une petite remarque :

j'aurai tendance à penser que la présentation de données sous forme de tableaux ne se justifie vraiment que quand c'est une présentation obligatoire. Soit donc dans le cas de ce que l'on appelle les tableaux complexes ( à double entrée ) car dans ce cas chaque cellule constitue l'intersection de deux éléments informant.

si un tableau à entrée simple peut évidemment être utilisé je trouve qu'il n'apporte rien de particulier par rapport à une présentation par liste. C'est le cas avec un support papier ça l'est certainement aussi dans une page web.

Le mercredi 19 janvier 2005 à 09:35, par Belgéric :: site :: #

Allez zou,
J'ajoute mon grain de sel et donne mon interprétation de données tabulaires.
Bien entendu, les rapports statistiques regorgent de données tabulaires. Ce qui en fait la tabularité?:

- Chaque ligne prise séparément doit avoir un sens (exemple: concerne un individu statistique). Jusque là, cela peut sémantiquement correspondre à une liste et des li.

- Chaque colonne prise séparément doit avoir un sens (les variables en statistique). La tabularité n'est intéressante que si l'on dispose de PLUS d'une colonne. N'oublions pas non plus que HTML définit <th> pour les headers, prouvant bien leur rôle utile. Sémantiquement, on pourrait encore envisager une liste de définitions dt.

- L'ensemble des lignes (et des colonnes) doit avoir un sens (regroupement, synthèse). Et un petit nom: c'est mieux. D'où le tag caption indispensable pour l'accessibilité. Et là, sémantiquement, il n'y a plus grand chose qui coincide...

En LaTeX, il est bien vu que toutes les tables soient encapsulées dans un float ET aient un petit nom. Le genre de résultats auquel on veut arriver est une liste des tables. Pour l'accessibilité, on devrait proposer des accès rapides aux sections. On devrait aussi faire la même chose pour les données tabulaires. Les vraies.
Il me semble donc que la décision de choisir une table pour représenter des données doit dépendre de la réponse à la question: cette table figurerait-elle dans une liste de tables (après la Table of Content, la Table of Tables ;-) )

Ajouter un commentaire

Les commentaires pour ce billet sont fermés.