[Coup de gueule 3] Maléfiques tableaux !

Bonjour,

Je sais que j'ai eu une période beaucoup plus radicale mais cela fait un bon bout de temps que l'expérience m'a amenée à revoir ma position... je suis totalement d'accord avec ce billet !

Amicalement,
Monique

Je ne sais plus qui disait ça, mais, le jour où l'on arrêtera de faire des site façon presse papier, on en aura fini de faire des mises en pages plus facile à réaliser en tableau.
C'est pas faux.

Code tableless qui sait faire, surtout. C'est un métier quand même, grmbl.

Pas du tout d'accord!
C'est le principe de base du xhtml que tu es entrain de mettre en cause. Le contenu différent du contenant, etc, etc...
Les tableaux doivent se limiter à la classification d'informations par tableaux.

Revenons aux tableaux ! Les CSS est la plus grosse daube que le W3C a inventé ! Et que dire du langage de programmation (qui s'ignore) XSLT ?!!

Ca chauffe ca chauffe !

N'oublions pas que nous sommes en train de vivre la préhistoire du réseau et de définir les règles et bons usages pour un monde virtuel... Alors forcément faut essuyer quelques peu les plâtres, mais nul besoin je pense de s'échauffer pour faire avancer le schimili ;)

Entièrement d'accord avec tous ces arguments ! Le "tableless" extremiste est une absurdité.

C'est pas pour te décevoir tfe mais l'XHTML n'a pas "beaucoup d'avenir" à mon avis et je ne suis pas le seul à le penser : developpeur.journaldunet....
et encore il ne parle même pas de productivité dans ce billet. Car il faut admettre que coder une page en XHTML strict qui soit identique sous tous les navigateurs est une activité très chronophage !

@tfe :
>C'est le principe de base du xhtml que tu es entrain de mettre en cause.

gni ? le fait de ne pas utiliser des tableaux ne fait pas du tout parti du principe de base xhtml. Le xhtml n'est qu'une formalisation xml du html. Les tags sont les mêmes qu'en html, avec la même sémantique etc.. Bref ce que tu dis n'a pas de sens.

@old school :
>Les CSS est la plus grosse daube que le W3C a inventé !

mais bien sûr. Tu n'a pas du bien comprendre les avantages de CSS toi par rapport au tag soupe.

par contre xslt oui, c'est trop merdique :-)

"Car il faut admettre que coder une page en XHTML strict qui soit identique sous tous les navigateurs est une activité très chronophage !"

Chronophage certes. Mais est-ce du à XHTML? Non. Si ce langage avait une syntaxe tordue et était peu lisible, je comprendrais qu'on l'accuse; mais en l'occurence, XHTML, HTML, même combat.
Le seul vrai problème est le faible support des CSS par certains navigateurs, et le corriger par l'emploi de tableaux signifie simplement retourner cinq ans en arrière... Si tout se passe bien, d'ici 5 ans, les CSS2 seront correctement interprétées par tous les navigateurs, et on sera toujours la à pester parce que CSS3, SVG, Canvas et autres joyeusetés ne seront pas comprises.

Effectivement, le tableau n'est pas interdit, comme le souligne Raphaël. Il faut qu'il soit linéaire (www.accessiweb.org/fr/gui... que le nombre d'imbrications soit limité, que l'attribut "summary" soit présent et soit vide lorsqu'il s'agit d'un tableau de mise en forme (www.accessiweb.org/fr/gui... et l'accessibilité d'un tableau de données peut être amélioré en reliant les entêtes aux cellules (www.accessiweb.org/fr/gui...

On peut effectivement faire ce que l'on veut avec CSS et même des horreurs comme une page qui sans CSS (qui peut par exemple être lu par une synthèse vocale) devient incompréhensible à cause d'un ordre dans la source incohérent et des possibilités de positionnement offertes par CSS.

A lire les réactions de certains en ce qui concerne (X)HTML et CSS on peut se dire que des sites comme Alsacreations ou Openweb on encore de beaux jours devant eux, et qu'il y a encore du travail en évangélisation, formation et démonstration.

Comme l'a dis giz404, le problème est surtout lié à l'implémentation des CSS dans les navigateurs. Le jour où ils comprendrons tous des choses comme display:table-cell alors ça évitera beaucoup de tableaux ou de bidouille.

Malheureusement ce n'est pas encore le cas, et on est parfois encore obligé de mettre un tableau lorsque l'on veut faire des colonnes de même hauteur ou centrer verticalement un élément.

Il faut juste choisir la moins mauvaise des solutions.
Avec un tableau de présentation on perd en séparation contenu/présentation mais si pour éviter ça il faut imbriquer XX divs et ajouter des hacks CSS alors on perd au niveau de la pérennité du code en plus de le rendre plus complexe (comme toujours avec les hacks...).

Moi je dis qu'il faut faire des compromis et pas essayer coûte que coûte de mettre en forme.

C'est la faute aux navigateurs, c'est la faute au CSS, c'est la faute au HTML.
N'empêche, il faut utiliser les outils qu'on a de la bonne façon. Quand on en aura d'autres, on fera mieux.

Si c'est galère de centrer verticalement, arrangez vous pour ne pas avoir le cas dans le design.

Un tableau *de mie en forme* n'est _jamais_ sémantique.

Avant de lancer un tel troll, tu pourrais au moins fournir ne serait-ce qu'un contre exemple.

Salut,

Je pense que à chaque cas, sa solution.

Tout à fait d'accord avec Raphaël.

Ne nous privons pas d'un occasion de réflechir et utlisons la technique, toute la technique pour résoudre les problèmes. Les sites à l'identique dans les différents navigateurs ce n'est pas mon problème. Chaque visiteur à son navigateur et ne voit pas ce que voient les autres, surtout avec Linx.
Perfectionnisme ???

Quand j'ai lu ca, j'ai regarde le calendrier a deux fois histoire de voir si on etait pas le 1er avril...

c'est un joli troll en tout cas, il faudrait plutot taper sur les navigateurs (comme l'a si bien dit giz404).

Moi je suis plutot sur le retour des frames, car j'en ai marre de mettre des includes dans toutes mes pages... ;o))

Pour faire une comparaison avec les voitures qui peuvent rouler au gpl, en disant que le gpl c'est de la **** car je n'en trouve pas dans toutes les stations et que toute les voitures ne peuvent pas l'utiliser, et si je veux que ma voiture l'utilise il faut que je mette les mains dans le camboui et que ca va me prendre du temps.

Je ne sais pas si mon exmple est parlant mais il ne faut pas lancer ce genre de propos sans etayer un minimum..

Ah, comme c'est bien dit ! Et pourtant, j'étais plutôt du côté des extrémistes il n'y a pas si longtemps. Mais il suffit de mettre un tant soit peu les mains dans le cambouis pour s'apercevoir qu'il n'y a pas toujours de solution miracle.


Romuald a raison : comment faire du style "colonnes de journal", de manière simple, et autrement qu'en tableaux ? Le web n'est pas conçu pour ça, et c'est d'ailleurs une aberration : vous pliez souvent votre écran en deux pour le lire, vous ?


En fait, il s'agit d'une bonne vieille politique du moindre mal...

Si l'on se place dans l'optique (XHTML plutôt HTML) de l'affichage sur écrans d'ordinateur avec option secondaire de restitution sur outils alternatifs, il est possible ou probable que l'utilisation de tables puisse être une solution parfois plus efficace que CSS, à la condition que la structuration du contenu soit pensée en conséquence (la linéarisation obéit certainement à d'autres contraintes dans ce cadre-là).

Mais si l'on se place dans l'optique (XHTML plutôt XML) d'une organisation de contenu indépendante de l'outil final de restitution, c'est moins sûr...

Si l'on se place dans l'optique d'une durée de vie de structure de contenu réduite aux quelques années à venir, l'usage de tables peut sûrement être envisagé. Mais si l'on se place dans celle de durabilité, il se peut que cela devienne à terme discriminant...

Je ne crois pas que le critère de choix prépondérant soit la "lourdeur" d'une solution ou d'une autre, mais plutôt la stratégie dans laquelle on inscrit le site. Est-il fait pour être encore consultable dans 5 ans sur un Ipod qui le lirait à haute voix tout en n'affichant que ses grands titres en 280 de large, ou est-il fait pour n'être consulté qu'aujourd'hui avec les outils dont nous disposons ?

La question de l'usage des tables de mise en forme dépasse je crois celle de leur pertinence dans tel ou tel cas de figure. Il me semble qu'elle relève plutôt de celle de la "mise en forme" elle-même : à quoi a-t'elle servi, à quoi sert-elle, à quoi servira-t'elle ?

L'appropriation du web par les graphistes à la fin du siècle dernier (et l'application de leurs savoirs-faire issus du "papier") a peut-être soulevé une question qui n'avait pas lieu d'être : celle (toujours issue du "papier") de l'inévitable relation entre le sens et l'aspect qu'il prendra.
C'est un problème qui est loin d'être résolu et il ne le sera pas tant que les acteurs du web (les producteurs et leurs clients) resteront dans ce questionnement... Paradoxalement Google est le site le + consulté au monde et il est quasiment privé de toute mise en forme ;-) - du moins est-elle réduite à sa plus simple expression.

Dans le cas du web - qui est un média récent - la question du "rendu" devrait à mon avis
être nettement disjointe : la question "tables ou pas ?" n'a finalement peut-être pas beaucoup d'importance en soi et dans l'absolu, encore une fois c'est une affaire de stratégie.
A priori je suis plutôt opposé à leur usage. Ce n'est pas de l' "ayatollisme sémantique" mais plutôt un pari sur une maturité de l'outil, maturité qui reste encore à créer.

@LaurentJ:
Oui evidemment, le XHTML regroupe la plupart des balises html, MAIS (et c'est le mais qui fait tout) reenvoie à un statut de "deprecated" un certains nombre d'autres balises...
(notemment beaucoup de balises de mise en forme).

@tfe : "MAIS (et c'est le mais qui fait tout) reenvoie à un statut de "deprecated" un certains nombre d'autres balises...
(notemment beaucoup de balises de mise en forme)"
->
Cela fera plaisir à Laurent Denis :
1- que dire de <b>, <i>, <tt>, <big>, <small>, etc. Toutes des balises de mise en forme parfaitement autorisées en XHTML ?

2- Vaut-il mieux préférer utiliser des imbrications de balises sans "sémantique" (<div>) au-lieu de balises <table>, employées à contre-usage, mais bien plus facile d'accès pour tous, y compris les personnes handicapées lorsqu'elles sont bien employées ?

Pour rappel (important) : le but de ce billet coup de gueule n'est pas de dire "il *faut* utiliser les tableaux de mise en page", mais "plutôt que de des bidouilles infâmes et hacks CSS pour obtenir un effet complexe, il faut parfois se demander si la simplicité n'est pas généralement la meilleure solution"

Il m'est jamais arrivé de devoir faire appel aux tables pour mettre en place un design.
Après peut etre est-ce le manque d'experiences, et le non-soucis de rendu sur Internet Explorer qui fait ca...
(Encore un message d'intégriste, d'après vous...)

Pour ma part, je ne recours aux tableaux que si j'ai des données tabulaires (affichage d'un forum ou tableau de question avec plusieurs libellés de réponse auxquels on a le choix entre les mêmes réponses). Pour le reste, si la mise en page obtenue sans tableaux est foireuse, c'est qu'il y a, quelque part, un problème de conception de la structure de la page. Autrement dit, "Vingt fois sur le métier remettez votre ouvrage". ;)

Enfin, je dis ça sans aucun extrémisme.

« Pour rappel (important) : le but de ce billet coup de gueule n'est pas de dire "il *faut* utiliser les tableaux de mise en page", mais "plutôt que de des bidouilles infâmes et hacks CSS pour obtenir un effet complexe, il faut parfois se demander si la simplicité n'est pas généralement la meilleure solution" »

Non, le truc c'est que, soit tu sais faire du HTML et on te paye pour cela, soit tu ne sais pas, tu gardes tes bricoles pour toi.
Je ne vais pas m'amuser à monter un avion avec mes potes pour le vendre alors qu'il ne respetera aucune réglementation de sécurité.

Entièrement d'accord avec Tfe quand il dit : "
C'est le principe de base du xhtml que tu es entrain de mettre en cause. Le contenu différent du contenant, etc.
Les tableaux doivent se limiter à la classification d'informations par tableaux."

Mais également d'accord avec Raphael, ne pas recourir aux tableaux ne doit pas engendrer une complication du code source ...

En sommes il est du devoir du concepteur Web de trouver une solution fiable et simple, se substituant aux tableaux, meme s'il doit pour celà renoncer au design choisit préalablement.

@Romuald : on ne parle pas de la même chose. Bien sûr et heureusement que les avions ne sont pas construits comme des sites Web, avec des budgets et des délais ridicules (d'ailleurs l'actualité d'Airbus prouve que c'est compliqué et cher).

A t'entendre, on devrait supprimer tous les sites qui ne sont pas validés et conformes aux standards. Avec de tels principes, c'est 99% du Web qui disparaîtrait.

N'oublie pas que ce support évolue à vitesse accélérée (qui aurait rêvé des applications 100% Web, aux Google Maps, à Ajax il y a dix ans ?) grâce à sa tolérance énorme et aux essais et erreurs qu'il permet. Dans ce domaine, si on impose des normes de qualité rigides, on tue l'essentiel de la créativité.

Le Caphar :
Supprimer les sites non standards, non. Les amateurs ont bien le droit de faire du bricolage et l'utiliser pour eux (à leurs risque et périls, et pour le web, c'est ce qui en fait sa force) mais vendre du travail d'amateur comme c'est encore trop largement le cas sur la toile, moi ça me dépasse. Et comme il y a trop de client néophyte, ça passe comme un d.. une lettre à la poste.
C'est là ou faire du site en tableau *et* le vendre parceQueC'estMoinsCheretQueLeClientEtRadin ça me gonfle.

Mouef, tu vois le grand méchant développeur face à la pauvre brebis cliente. Mais celui qui a fait ce que le marché de l'informatique est devenu c'est le client... Le developpement merdique, les SSII, etc tout ca ne sont que des adaptations à ce marché.

Je suis peut etre un peu trop naïf mais pour moi personne n'aime coder de la merde. (Ok j'occulte les compétences dans mon raisonnement)

@LaurentJ ->
Je ne vois pas ce que tu reproche à XSLT/XPATH c'est l'un des outils le plus puissant de XML. C'est un langage de programmation plus déclaratif que procédural c'est peut être ça qu'il fait peur, mais je le répète c'est super puissant.

Mouaip, billet et fil de commentaires à bookmarker pour le prochain changement de cycle et de pathos.

<table> pour remédier aux carences d'implémentations pour le centrage vertical et la mise en colonnes...

... Oui certes, pour le centrage vertical c'est une évidence que j'ai dite il y a presque trois ans. Au passage c'est sur ce sujet précis qu'on a eu notre premier échange Raphael ;-)

Pour les colonnes, ben faut voir...

... Mais là n'est pas la question !!!

de quelles carences parle t'on ???

. Celles des css > il y en a

. Celles relatives aux implémentations des agents utilisateurs > Il y en a aussi (multi troll tous azimut inside)

. Ou bien les carences navrantes des développeurs qui ne font aucun effort en vue d'une bonne connaissances et d'une bonne maitrise des css.

Qui ne se posent que le minimum de questions sur un code html intelligemment construit.

Et qui n'ont aucune notion du fait que les css s'appuient justement sur ce code pour s'élaborer de manière intelligente et efficace.

Donc préconisation normative toute personnelle ;-)

Prima, le flux.
Ensuite, le html et seulement le html > no style, no <div>, no <table>.
Ensuite les css.
Ensuite, et seulement si besoin est, les <div>.
Ensuite et seulement en bout d'une course effrénée et exigeante le détournement de balise acceptable que peut constituer l'emploi des <table>

Mais pourquoi appelles-tu ce billet un coup de gueule ?

Cela ne tombe-t-il pas dans le bon sens ?

Toudac' avec clb 56
_one/*Da flux (optimisé pour lecture vocale avec le main-menu interminable en fin de page+ skiplinks, c'est vrai que l'oeil de lynx il est rapide)
_two/*Da Core Xthml (et prop' siouplé, ça parle déjà avec du sens cho petites balises... et de la table juste quand y n'en fô avec parcie et maunie)
_three/*Da CSS (ya bô pour l'regard ! mais si t'as un user ou un client qui t'la chinte tu fais pas l'poids)
_four/*Da blocs de div pour ranger un peu ses affaires (on n'est pas des sauvages)
_get up !
Vivement HTML5 !! Youpi, vive le dev' !!!
FeelinGhaPPy