Design à base de tableau : et pourquoi pas???

Bonjour,

Je suis certain que pas mal de personnes viennent lire ce sujet en se disant "ça sent le troll à plein nez". Le titre est volontairement assez provoquant, mais la question est bien réelle.

Je lis partout qu'il ne faut pas utiliser de tableau pour faire le design des sites. C'est pas accessible, c'est lourd, c'est pas prévu pour ça, ça respecte pas les standards.... Mettons de coté les apprioris, et voyons les faits :
Je ne considère que le cas où on utilise UN seul tableau pour le design du site (juste pour séparer le header, les menus, le contenu central, et le footer)

- Un design en tableau permet d'avoir un rendu graphique relativement propre (pas de soucis de compabilité avec IE par exemple, je n'en dirais pas tant des div avec les marges, leur placement etc)

- On dit que les tableaux allourdissent le code. Soit. Mais placer un div en spécifiant sa largeur, sa position horizontale, verticale, les margin, padding etc, je en suis pas certain que ce soit mieux...

- Imaginons quelqu'un qui est mal voyant, qui veux fortement grossir la police du site : avec un tableau, les colonnes s'élargieront, si besoin (cas d'un menu étroit, contenant un mot relativement long par exemple). Avec des divs, au pire le mot va dépasser du cadre et risquer de couvrir un autre texte, au mieu il sera partiellement caché. Dans tous les cas, pas très lisible. Oui je sais, un site n'est pas fait pour être trop grossi, mais l'utilisateur est roi. S'il veux le grossir au lieu d'utiliser des outils spécialisés (loupe etc), il doit pouvoir le faire, et le site devrait pouvoir rester lisible!

- En termes de présentation, maintenant : vaut-il mieux un site utilisant un tableau, mais bien présenté, ou un site utilisant des divs uniquement, mais présentant des bugs d'affichage dus à des problèmes de navigateurs interprétant plus ou moins bien le code?

- Parlons maintenant de l'odre d'affichage : avec un tableau, tout s'affiche de haut en bas, et de gauche à droite. Avec les divs, l'ordre d'affichage est chamboulé, lorsqu'on a des menus latéraux (affichage des menu gauche, puis droit, pour seulement le centre). Pourtant, le centre est souvent ce qui contient le contenu important. Il semblerait logique qu'il s'affiche avant le menu droit...

- prenons un autre exemple, où les tableaux sont souvent "déconseillés" : les formulaires. Là encore, gros problèmes s'il on met un <label> de largeur fixe : si le texte grossi, le label est caché. Et essayez de centrer correctement sur la page, un formulaire à base de div, de p, et de label... C'est un casse tête. Avec un tableau, ça va tout seul.

- Soyons réaliste : les designs actuels sont tout de même des design tabulaires (on a bien des "cases", qui souvent sont cote à cote, de même hauteur, contenant du texte....). Et faire un design sans tableau posera toujours des soucis d'accessibilité (c'est assez marrant, quand on prone l'accessibilité de ce type de design). Souvent dues au grossissement des mots.

Pour le moment, j'ai toujours utilisé des divs pour mes design, mais je dois reconnaître que les tableaux me tentent de plus en plus : ils sont mieux interprétés par les navigateurs, se mettent en place plus facilement pour un résultat meilleur (moins de bugs d'affichage).

Maintenant, avant que je tombe dans le coté obscure de la force, convainquez-moi de l'utilité des divs, dans un design de site! (je ne suis pas contre les divs, mais contre les design 100% avec div, et sans aucun tableau)

Hello,

Seuls les fanatiques intégristes (stupides ?) vont encore actuellement te répondre "il ne faut jamais utiliser de mise en page par tableaux".

J'ose espérer que les membres d'Alsa ne sont pas si intégristes et regardent plus loin que le bout de leur nez

Ah, au fait, voici un billet de blog récent pondu ici :
http://blog.alsacreations.com/2007/03/06/335-coup-de-gueule-3-malefiques-tableaux

PS : je ne développerais pas chacun de tes points car il y'aurait quand-même source à débat (plusieurs, sans vouloir te vexer, témoignent d'une mauvaise connaissance des mises en pages sans tableaux)... et mon week-end sera trop chargé. Mais je vais suivre cette discussion avec attention
Modifié par Raphael (21 Jul 2007 - 08:26)

Helldream a écrit :
Je ne considère que le cas où on utilise UN seul tableau pour le design du site (juste pour séparer le header, les menus, le contenu central, et le footer)

Peu ou pas d'objections particulières dans ce cas.

Tout comme Raphaël: j'approuve globalement, mais pour ce qui est des différents points que tu soulève il y a quelques erreurs, ainsi que des choses qui pourraient être débattues séparément.

Helldream a écrit :
- Parlons maintenant de l'odre d'affichage : avec un tableau, tout s'affiche de haut en bas, et de gauche à droite. Avec les divs, l'ordre d'affichage est chamboulé, lorsqu'on a des menus latéraux (affichage des menu gauche, puis droit, pour seulement le centre). Pourtant, le centre est souvent ce qui contient le contenu important. Il semblerait logique qu'il s'affiche avant le menu droit...

Au contraire Avec des floats et des marges négatives, on peut mettre le contenu avant les menus, il s'affichera en premier

Bonjour

Un exemple : je gère le site d'un festival qui a lieu chaque année. Chaque année la charte graphique change et la présentation du site aussi : des fois les menus en haut, des fois sur le côté, des fois le contenu principal avant, des fois après, etc.). Tous les contenus étant appelés en PHP et le balisage structurel très "sémantisé" (découpe séquentielle en éléments cohérents) il suffit de modifier d'une année sur l'autre l'unique feuille CSS.

Un autre exemple : un client a l'an dernier radicalement modifié l'organisation des contenus du site, ce qui a bouleversé tout le système des menus. Alors par exemple le menu horizontal de 4 items est passé à 7, ce qui a nécessité de redescendre la colonne de droite pour laisser la place à ce menu soudain devenu plus large....

Tu sais faire ça avec un tableau sans reprendre toutes les pages une par une ?
Faut pas penser qu'à l'aspect, faut penser aussi à la prod.

Une mise en page en tableaux n'est pas à éviter pour des raisons d'accessibilité mais de maintenance et de souplesse ; mais aussi (surtout ?) d'interopérabilité à venir : rien ne dit que demain un UA particulier ne considérera pas qu'une balise <table> sera à traiter comme telle : des informations à gérer en X et en Y, le croisement des colonnes et des rangées renvoyant du coup une restitution aberrante. Ça n'est pas parce qu'aujourd'hui aucun UA ne sait faire ça (utiliser cette balise exclusivement dans le sens qu'elle porte) que c'est acquis dans la durée.

Raphael a écrit :
Hello,

Seuls les fanatiques intégristes (stupides ?) vont encore actuellement te répondre "il ne faut jamais utiliser de mise en page par tableaux".

Ce n'est pas tout à fait cela.

Seuls les membres de ce forum qui n'ont pas encore compris qu'il fallait abandonner le fanatisme intégriste du tableless répondront cela.

C'est assez normal en fait car nous sommes actuellement tous en recherche de nouveaux fanatismes paradigmatiques...


... Et pourtant, ce n'est pas ça qui manque




Bref...
Modifié par Christian Le Bouler (21 Jul 2007 - 17:09)

Salut,

Raphael a écrit :
Hello,

Seuls les fanatiques intégristes (stupides ?) vont encore actuellement te répondre "il ne faut jamais utiliser de mise en page par tableaux".

J'espère que non, mon site pro est fait avec un tableau 2 lignes et 2 colonnes. Il respecte la sémantique web, il se linéarise tout bien et est, je le crois, accessible.

Pas la pelle

Effectivement, ce n'est pas tout à fait cela.
Ce n'est pas une question de fanatisme intégriste pro- ou anti-table, c'est une question purement pratique.
Pour certains projets les tables sont inadaptées en termes de maintenance, d'évolutivité, de souplesse, etc. Je trouve que ça forme un cadre rigide qui oblige à jongler avec les colspan et les rowspan et dont la gestion est plus complexe - amha - que des objets "autonomes" dont on gère la position de façon indépendante. Les possibilités offertes par CSS sur ces objets autorise en fonction du média (imprimante par ex) une gestion beaucoup plus fine qu'une table.

Helldream a écrit :
-Un design en tableau permet d'avoir un rendu graphique relativement propre (pas de soucis de compabilité avec IE par exemple, je n'en dirais pas tant des div avec les marges, leur placement etc)
- En termes de présentation, maintenant : vaut-il mieux un site utilisant un tableau, mais bien présenté, ou un site utilisant des divs uniquement, mais présentant des bugs d'affichage dus à des problèmes de navigateurs interprétant plus ou moins bien le code?
-ils sont mieux interprétés par les navigateurs, se mettent en place plus facilement pour un résultat meilleur (moins de bugs d'affichage).

Personnellement je me fous complètement qu'il y ait un écart de 10px sur IE ou FF vu que personne ne consulte un site sous deux navigateurs en simultané .

Qu'en revanche tout utilisateur puisse restituer un contenu selon l'UA qu'il détient est primordial. Jusqu'à preuve du contraire - preuve qu'on attend toujours - un design en tableaux n'accroît pas significativement cette restitution. En revanche dans certains cas elle peut la restreindre.

Si en plus c'est juste pour séparer entete, menus, contenu et pied de page comme le dit Helldream (c'est-à-dire en gros 3 <tr> dont 2 en colspan="2" et celui du menu+contenu en 2 <td> côte à côte), désolé ça ne présente aucun intérêt décisif, si ce n'est effectivement d'obtenir un contrôle plus absolu des alignements et marges :

Helldream a écrit :
Je ne considère que le cas où on utilise UN seul tableau pour le design du site (juste pour séparer le header, les menus, le contenu central, et le footer)

Pour moi c'est tout le contraire, j'utilise régulièrement les tables mais pour un autre besoin : structurer le contenu principal des pages en cours dans la <div>, par exemple titre de paragraphe+image d'illustration à gauche, texte courant à droite.

Helldream a écrit :
Maintenant, avant que je tombe dans le coté obscur de la force, convainquez-moi de l'utilité des divs, dans un design de site!

Alors avant que je tombe à mon tour dans le coté obscur de la force, convainquez-moi de leur incontes<table> utilité dans une structure de site! (on laisse tomber le côté design pour le moment)

Arsene a écrit :

Alors avant que je tombe à mon tour dans le coté obscur de la force, convainquez-moi de leur incontes<table> utilité dans une structure de site! (on laisse tomber le côté design pour le moment)

Arsene ! T'es trop méchant

...

+1

Merci de vos nombreuses réponses, j'avais un peu peur de me sentir seul avec mon post . Je vais prendre le temps qu'il faut, pour répondre à toutes vos interventions. N'y voyez pas là un signe de suffisance (je ne pense pas détenir la vérité universelle sur les div et les table ), mais bien un retour d'expérience sur les points que vous avez sité.

a écrit :
Un exemple : je gère le site d'un festival qui a lieu chaque année. Chaque année la charte graphique change et la présentation du site aussi : des fois les menus en haut, des fois sur le côté, des fois le contenu principal avant, des fois après, etc.). Tous les contenus étant appelés en PHP et le balisage structurel très "sémantisé" (découpe séquentielle en éléments cohérents) il suffit de modifier d'une année sur l'autre l'unique feuille CSS.

Dans ce cas, les divs sont intéressantes, mais c'est un cas relativement particulier. Je doute que tu changes tous les jours un design du tout au tout

a écrit :
Un autre exemple : un client a l'an dernier radicalement modifié l'organisation des contenus du site, ce qui a bouleversé tout le système des menus. Alors par exemple le menu horizontal de 4 items est passé à 7, ce qui a nécessité de redescendre la colonne de droite pour laisser la place à ce menu soudain devenu plus large....

Tu sais faire ça avec un tableau sans reprendre toutes les pages une par une ? biggol
Faut pas penser qu'à l'aspect, faut penser aussi à la prod.

La solution est simple : avoir un fichier contenant le menu (qui est identique sur toutes les pages), que tu inclue sur les pages nécessaires. Sans parler tout simplement d'utiliser un controleur principal, qui s'occupe d'afficher le header, menu, footer, et contenu central, selon la page appelée Bref sur un site bien conçu, que le design soit fait à base de div ou de table, c'est facilement changeable.

a écrit :
Une mise en page en tableaux n'est pas à éviter pour des raisons d'accessibilité mais de maintenance et de souplesse ; mais aussi (surtout ?) d'interopérabilité à venir : rien ne dit que demain un UA particulier ne considérera pas qu'une balise <table> sera à traiter comme telle : des informations à gérer en X et en Y, le croisement des colonnes et des rangées renvoyant du coup une restitution aberrante. Ça n'est pas parce qu'aujourd'hui aucun UA ne sait faire ça (utiliser cette balise exclusivement dans le sens qu'elle porte) que c'est acquis dans la durée.

Interpolabilité, je peux comprendre, même si je doute que ce changement aie lieu un jour. Souplesse, à la limite (il est vrai qu'il est plus facile de modifier un détail sans toucher au reste sur un design à base de div). Maintenance, là par contre, je ne suis pas du tout d'accord : un design à base de div te coutera beaucoup plus de temps, pour traquer les bugs d'IE, et bidouiller (je ne vois pas d'autre mot) pour les corriger! Mais bon, il faut espérer qu'avec le temps, ce problème soit réglé...

a écrit :
Personnellement je me fous complètement qu'il y ait un écart de 10px sur IE ou FF vu que personne ne consulte un site sous deux navigateurs en simultané cligne .

Dans la plupart des cas, je suis tout à fait d'accord. Mais si ton design comporte des image découpées (c'est souvent le cas quand tu bosses avec un graphiste par exemple), s'il y a un décallage de 10px... :S

a écrit :
Qu'en revanche tout utilisateur puisse restituer un contenu selon l'UA qu'il détient est primordial. Jusqu'à preuve du contraire - preuve qu'on attend toujours - un design en tableaux n'accroît pas significativement cette restitution. En revanche dans certains cas elle peut la restreindre.

En termes de contenu, en effet, il n'y a pas de grand changement. Mis à part les mots coupés dans les menus en cas de grossissement des polices, ce que je trouve grave (car souvent les menus servent par définition à naviguer sur le site. Donc si certains mots deviennent illisibles...). C'est pour moi le gros point fort qu'ont les tableaux.

a écrit :
Si en plus c'est juste pour séparer entete, menus, contenu et pied de page comme le dit Helldream (c'est-à-dire en gros 3 <tr> dont 2 en colspan="2" et celui du menu+contenu en 2 <td> côte à côte), désolé ça ne présente aucun intérêt décisif, si ce n'est effectivement d'obtenir un contrôle plus absolu des alignements et marges :

Mais hélas, quelque fois, rien que cela peut devenir complexe avec des divs! Sans parler les mots coupés, avec un design complexe contenant des images, il arrive régulièrement qu'il y aie par exemple des soucis de quelques pixels sous IE6, lorsqu'on place les divs, ce qui fait très mauvais genre dans certains cas! Pareil si tu veux mettre (je n'en ai jamais eu besoin) deux menus de taille rigoureusement identique... Avec un tableau, ça va tout seul.

a écrit :
Au contraire smile Avec des floats et des marges négatives, on peut mettre le contenu avant les menus, il s'affichera en premier

C'est vrai, mais pour moi c'est du bidouillage : imagine que tu doives modifier la largeur d'un menu, tu es obligé de remodifier toutes tes marges... C'est d'après moi une perte de temps . C'est bien dommage qu'il soit pas possible, simplement, d'afficher dans l'ordre "menu gauche, centre, menu droit", à base de floats simplement...

Pour résumer, à part les bugs qui seront corrigés un jour pour IE (merci Firefox, sans lui je doute que ça aurait changé), ce qui me choque, c'est :
- l'aspect présentation, qui est plus pratique à base de tableaux; (discutable, je vous l'accorde, s'il n'y avait plus de bugs)
- la coupure des mots quand on zoome le texte. Là je trouve cela annormal de ne pas pouvoir avoir un option permettant d'élargir le div (et de pousser les autres divs qui sont à coté), lorsqu'un mot est trop long pour s'afficher entièrement, comme c'est le cas pour les tableaux. C'est un détail, qui pour moi est important...
Modifié par Helldream (21 Jul 2007 - 23:30)

Tu m'excuseras Helldream, mais les trois quarts de tes arguments reflètent une certaine méconnaissance ou manque de maitrise du positionnement CSS.

Je ne relève pas tout, mais quand même:

Helldream a écrit :
C'est bien dommage qu'il soit pas possible, simplement, d'afficher dans l'ordre "menu gauche, centre, menu droit", à base de floats simplement...

Ben si, c'est parfaitement possible.

Helldream a écrit :
l'aspect présentation, qui est plus pratique à base de tableaux

Je dirais pour ma part que c'est l'aspect grille qui est plus pratique à base de tableaux. Mais toute présentation n'a pas à reposer sur une grille.

Helldream a écrit :
je trouve cela annormal de ne pas pouvoir avoir un option permettant d'élargir le div (et de pousser les autres divs qui sont à coté), lorsqu'un mot est trop long pour s'afficher entièrement, comme c'est le cas pour les tableaux

Voir du côté de... display: table-cell.
Ceci dit, d'une part ce type de comportement du bloc n'est pas forcément toujours intéressant, et d'autre part les problèmes de dépassement et chevauchement de texte ne sont pas si fréquents (pour une page intégrée correctement, s'entend).

<Modération: message supprimé. Merci d'adopter un ton courtois />
Modifié par Florent V. (22 Jul 2007 - 01:56)

Christian Le Bouler : Bien que me sentant bizarrement agressé (j'éviterais en passant un jeu de mot d'un gout douteux), je ne désire pas me disputer avec toi sur ce forum (nous avons déjà eu un petit différent ensemble sur un autre sujet, et je ne désire pas le renouveler). Cependant, je tiens à préciser que je n'aprécie pas ta façon de répondre, que je trouve assez agressive. Tu devrais t'inspirer des réponses de Florent V., qui semble aussi être du même avis que toi, mais qui sait dire les choses de façon plus courtoise, et surtout plus constructive. Passons sur la forme, et intéressons-nous au contenu (de Florent V., j'entend, car de ton post, Christian, si tu le relis, tu verras qu'il n'apporte pas de réponse, à par un vague "je t'invite avant tout à travailler"... Avec ça, je n'irais pas loin).
Si tu as des liens à me proposer sur la "compréhension du CSS", concernant les thèmes cité (à savoir la mise en page), par contre, je suis preneur. Mais par pitié, ne me sorts pas "cherches sur google", ou "il y en a plein sur ... (par exemple Alsacreations)". Sur le net, il y a des milliers de sujets parlant du CSS de façon plus ou moins complète, et tu comprendras qu'il est humainement impossible de tous les lire. J'en ai lu certain, visiblement pas les bons, ou pas assez.
Comprenons nous bien, je ne veux pas t'agresser, mais juste te faire comprendre un point : je viens sur ce forum justement pour apprendre, corriger mes défaut/erreurs, et partager mes opinions. C'est pour moi la meilleure méthode pour progresser (je lis biensûr régulièrement des tutos sur les sujets traités, avant d'en parler, pour ne pas parler de ce que je ne connais pas au moins un minimum). Or, j'ai l'impression que tes posts sont régulièrement agressif : en relevant quelques mots, on peux trouver par exemple "stupidité trolleste", "logorrhée d'incompétent complet", "pathétique", "complètement stérile", "de manière aussi jubilatoire et inconsistante"... Le tout dans un seul post. Tu remarqueras que dans l'ensemble du sujet, tu es le seul dans ce cas. Je trouve cela dommage, surtout si tu as des connaissances. Je ne pense pas que tu sois idiot, loin de là, mais tu ne dois visiblement pas être doué en pédagogie. Je suis certain que tu as toi aussi fait des erreurs de jugement, lorsque tu étais à mon niveau d'ancienneté dans le secteur. Tu as pu les corriger avec le temps, j'espère bien en faire autant, et c'est pour ça que je suis ici. Car sans dialogue, on ne peux justement pas corriger ses idées fausses.

Florent V. : merci de ta réponse, ELLE est constructive. En effet, comme marqué plus haut, je ne prétend pas maitriser le CSS. Si mon avis était définitif, je ne verrais pas d'interrêt à venir en parler ici. Mon but est justement de corriger mes apprioris, afin d'avancer. J'ai déjà écumé pas mal de tutos, mais hélas tout n'est pas forcément expliqué. Et il est impossible de TOUS les faire.
- Pour les floats, j'avais cru comprendre que cela fonctionnait comme ceci :
affichage du menu en float: left; affichage du menu en float: right; et enfin affichage du contenu central. Il y a d'après ce que tu dis une autre utilisatation possible que je ne connais pas, je chercherais un peu mieux, pour ne pas mourir idiot
- Pour la présentation, on peux dire en effet que c'est l'aspect "grille" qui est assez intéressant, lorsqu'on doit placer un design découpé. A part ça, il faut reconnaitre que le reste est assez équivalent aux divs.
- Enfin, je ne connaissais en effet pas le display : table-cell (j'en étais resté au display : block...). Là encore j'irais me documenter. Il est vrai que le chevauchement de texte est plutot rare : je rencontre ce problème dans 2 cas précis : les menus étroits, pour des design compatible en 800*600 en particulier, et pour les formulaires à base de <label>, pour pour ce dernier cas, je suis passé à des tableaux, plus pratiques à positionner, et à mettre en forme. Et on peux en effet parler de données tabulaires, les données saisies sur un même ligne étant en rapport.
Je te remercie d'avoir pris le temps de corriger mes apprioris, c'est d'après moi comme cela qu'on progresse, et c'est tout ce que je demande Si d'ailleur tu as décelé d'autres erreurs, n'hésite pas à m'en faire part, que je sache où j'ai faux.
Modifié par Helldream (22 Jul 2007 - 01:53)

Avertissement de modération:
J'ai supprimé ci-dessus un message peu constructif et au ton déplacé. Merci d'éviter de transformer ce sujet en pugilat. Si besoin, d'autres messages ou parties de messages pourront être supprimés, ce sujet fermé, etc. Tâchons d'éviter cela.

a écrit :

Et on peux en effet parler de données tabulaires, les données saisies sur un même ligne étant en rapport.

L'id de l'input et le for du label exprime déjà une relation entre les deux, qui est nécessaire et suffisante. Donc, à mon avis, inutile d'en faire trop sémantiquement.
A noter que mon opinion n'aurait pas été très différent avec celui qui aurait proposé une liste non ordonnée ou de définition, que je trouve tout aussi inutile et déplacée dans ce cas. Des paragraphes sont ici amplement suffisants.

De manière générale, je considère des données comme tabulaires à partir du moment où il y en a à répartir pour au moins 3 lignes et 3 colonnes, sauf cas très particuliers.
En-dessous, tout tableau me paraît comme étant là uniquement pour la présentation et/ou inadapté à son utilité.

Bien que tableau ne rime pas forcément avec inaccessible, il est pour moi des cas où ce n'est qu'alourdissement inutile de structure, et tu viens d'en donner un magnifique exemple.

J'espère ne pas avoir été agressif avec mes propos.

Helldream a écrit :
- Pour les floats, j'avais cru comprendre que cela fonctionnait comme ceci :
affichage du menu en float: left; affichage du menu en float: right; et enfin affichage du contenu central. Il y a d'après ce que tu dis une autre utilisatation possible que je ne connais pas, je chercherais un peu mieux, pour ne pas mourir idiot

C'est en effet la structure présentée dans un tutoriels de «design en trois colonnes» sur Alsacréations, qui permet d'avoir une colonne centrale fluide et des colonnes latérales de largeur déterminée (pixels, pourcentages...).

Si on est sur un design en largeur fixe (en pixels) ou avec deux ou trois colonnes toutes déterminées en pourcentages, on pourra utiliser les flottants avec une structure de ce type:

[b]HTML:[/b]
<div id="gauche">...</div>
<div id="centre">...</div>
<div id="droite">...</div>

[b]CSS:[/b]
div#gauche {
	float: left;
	width: 20%;
}
div#centre {
	float: left;
	width: 60%;
}
div#droite {
	overflow: hidden;
	height: 1%; /* à déclarer pour IE6 uniquement via un commentaire conditionnel */
}

Et voilà, l'ordre visuel et l'ordre du flux HTML coïncident.

Si on veut une structure du type 200px + fluide + 200px, avec ordre du flux correspondant à l'ordre visuel, il sera peut-être possible d'utiliser le positionnement absolu pour la colonne de droite? Ça dépendra de l'existence ou non d'un pied de page ou de contenus en dessous des trois colonnes, et de la longueur attendue du contenu dans la colonne de droite.

Enfin, ne blamons pas les CSS pour leur incapacité à obtenir le même rendu qu'avec les tableaux, vu que les valeurs "table" et "table-cell" de la propriété display permettent justement d'obtenir ce rendu! Cette propriété est d'ailleurs correctement implémentée par la plupart des navigateurs sauf un (je vous laisse deviner lequel... ).

QuentinC a écrit :
De manière générale, je considère des données comme tabulaires à partir du moment où il y en a à répartir pour au moins 3 lignes et 3 colonnes, sauf cas très particuliers.

Position intéressante. Je note.

QuentinC a écrit :
En-dessous, tout tableau me paraît comme étant là uniquement pour la présentation et/ou inadapté à son utilité.

Inadapté, faut voir... si son utilité est justement d'obtenir à peu de frais un rendu graphique via une structure en tableau non problématique, rendu que l'on aurait eu beaucoup plus de mal à obtenir sans (soit à cause de connaissances incomplètes des CSS, soit à cause de l'implémentation limitée des CSS par certains navigateurs), je trouve ça tout à fait adapté.

Voir l'article pointé par Raphaël au début de ce sujet.

Bonjour

Helldream a écrit :
Mais si ton design comporte des image découpées (c'est souvent le cas quand tu bosses avec un graphiste par exemple), s'il y a un décallage de 10px... :S

Le problème dans ce cas n'est pas du tout dans la façon dont le contenu est présenté mais dans la façon dont il est initialement pensé. Si un graphiste (j'en sais quelque chose, je suis graphiste) envisage une interface web comme du "papier numérique", c'est-à-dire selon des savoir-faire issus de l'imprimerie, ce n'est pas au webdesigner de torturer le code - et accessoirement ses méninges - pour arriver à ce résultat. Le média web a ses spécificités et tout graphiste compétent devrait en tenir compte, de même qu'il tient compte des spécificités des autres médias.

Helldream a écrit :
Mis à part les mots coupés dans les menus en cas de grossissement des polices, ce que je trouve grave (car souvent les menus servent par définition à naviguer sur le site. Donc si certains mots deviennent illisibles...). C'est pour moi le gros point fort qu'ont les tableaux.

- la coupure des mots quand on zoome le texte. Là je trouve cela annormal de ne pas pouvoir avoir un option permettant d'élargir le div (et de pousser les autres divs qui sont à coté), lorsqu'un mot est trop long pour s'afficher entièrement, comme c'est le cas pour les tableaux. C'est un détail, qui pour moi est important...

+1 avec Florent... Là encore désolé mais l'argument se retourne : un design fluide bien pensé et bien testé supportera un agrandissement de polices de 3 fois. Il existe un certain nombre de techniques pour ça.

Helldream a écrit :
un design à base de div te coutera beaucoup plus de temps, pour traquer les bugs d'IE, et bidouiller (je ne vois pas d'autre mot) pour les corriger!

Non, sûrement pas. Quand on connaît un peu IE6 on sait quels sont ses quelques défauts et on les anticipe dès le départ. Je peux t'assurer que dans AUCUN de mes sites les commentaires conditionnels dépassent trois lignes (en gros gérer les min-width, les tranparences PNG et éventuellement placer un ou deux divs en position:relative... et ça s'arrête là.)

Ce qui prend beaucoup de temps, c'est de concevoir un document web sur Photoshop/Image Ready et de vouloir le reproduire à l'écran. C'est sûr que quand ça c'est fini les vrais problèmes commencent et les heures s'accumulent vite Les problèmes que tu évoques me semblent surtout liès à cette méthode de travail, associée à une utilisation incomplète des possibilités offertes par les langages. C'est sûr qu'apparemment ça va plus vite de faire une table-image générée directement en Html sous Photoshop, mais le temps nécessaire à tout reprendre pour la rendre conforme aux usages, standards et résultats attendus est beaucoup, beaucoup, beaucoup plus long.

Ce qui ne prend pas beaucoup de temps c'est d'imaginer dans sa tête une structure générale, ensuite d'écrire tout le document en pur code linéaire (Hn, p, li, etc... de toute façon il faudra le faire, et puis c'est surtout beaucoup de copier-coller), ensuite de le découper en <divs> cohérents, après de mettre en place ces objets à l'écran les uns par rapport aux autres par CSS (là je suis adepte du border:red, green, yellow, blue, etc), ensuite de passer tout ça en style (typo, couleurs, images-background et consorts), et à la fin de rajouter les événements JS, le tout étant testé multi-navigateurs et validé W3C à chaque étape. C'est là qu'on gagne du temps et qu'on ne se grille pas inutilement les neurones avec de pseudos-problèmes IE - le "bidouillage" dont tu parles - qui n'ont en définitive rien à voir avec IE lui-même mais avec la méthode de travail adoptée.

Donc en gros j'aurais tendance à dire que la solution tableaux est la meilleure des solutions pour qui ne se sent pas apte à en utiliser une autre pour obtenir un certain rendu, mais qu'en terme de souplesse d'utilisation, d'évolutivité, de cohérence de structuration, d'interopérabilité présente ou à venir, de restitution multi-UA, etc etc etc - bref, tout ce que devrait exiger un document web - c'est une solution pleine d'insuffisances. Disons pour être plus précis que dans la gamme des insuffisances on a déjà assez de soucis avec celles de Xhtml et CSS pour ne pas se rajouter celle-là en plus.

Dans ce sens - et dans celui-là seulement - je suis un pur intégriste ayatollesque du tableless qui réserve l'utilisation des tables à son usage, du moins tant qu'on ne m'aura pas expliqué pourquoi le contraire est mieux (re- )

En passant et tant que j'y suis, je me permets d'indiquer le petit article suivant:
Quelle démarche suivre pour intégrer une maquette en page HTML/CSS ?
C'est une méthode personnelle plus qu'une méthode «scientifique» ou éprouvée, mais ça peut donner des idées.

Florent V >
Si tu sous-entendais la structure actuelle du forum, c'est effectivement un cas particulier qui ne rentre pas dans mon 3/3.

a écrit :

height: 1%; /* à déclarer pour IE6 uniquement via un commentaire conditionnel */ 

Question idiote : A quel bug d'IE fais-tu ici référence ?

Bonjour,

a écrit :
C'est une méthode personnelle plus qu'une méthode «scientifique» ou éprouvée, mais ça peut donner des idées.

Malheuresement, le problème est beaucoup plus profond ... l'intégration n'est pas le problème en soit ; le problème reste la qualité de la maquette et la perception qu'à le graphiste du web. (Je sais de quoi je parle ). A partir de là, l'intégration sera de plus ou moins bonne facture selon le travail réalisé en amont.

<J'aime pas>Tableless, FullCSS & cie ça veut rien dire ...</J'aime pas>