Mise En Page En Div..., Mais on arrête quand ?

Voilà,

Tout le monde sait qu'une mise en page avec des tableaux, c'est le mal.
Cependant, à quel moment peut-on se permettre d'utiliser des tableaux ?

Je précise ma question:
Pour faire la mise en page des éléments de formulaire (Page d'inscription par exemple). Je trouve bien plus pratique de faire un tableau pour enligner les input ensemble si le texte devant n'est pas de la même longueur.

Avec des Divs, ca serait très compliqué à faire, le principe s'applique t'il toujours ou doit-on se servir de notre tête ? (et dans un tel cas j'ai du manquer un tutorial)

Les tables sont tolérées pour la présentation de données. Ca ne me semble pas une hérésie de les utiliser dans le cadre d'un formulaire. Par contre, les utiliser pour mettre en place un design graphique, c'est autre chose...

Puisque tu ne sais pas utiliser google, on va rester simple:

http://www.siteduzero.com/tuto-3-7596-1-al...s-tableaux.html

Les tables pour de la mise en forme de données non-tabulaires, c'est caca, poubelle...

Faut arrêter les "C'est caca, unix c'est mieux" et autre délires d'informaticiens.
Les div, c'est compliqué simplement parceque l'on a pris l'habitude d'utiliser des tableaux.
Les tableaux doivent être utilisés pour afficher des informations tabulaires. Pas pour faire de la mise en page.
Maintenant, chacun fait comme bon lui semble.
Faire des formulaires sans tableau, ce n'est pas très compliqué. Voyez les formulaires de PBeM News par exemple, ils sont en div. J'utilise les label pour "tabuler".
Et pour reprendre le terme "C'est mal", c'est bien d'utiliser les balises pour ce qu'elles ont été faites. Et c'est bien de s'entraîner maintenant à prendre de bonnes habitudes

Le sujet est l'objet de débats animés depuis pas mal de temps...
Par exemple dans cet article de Raphael Goetter et dans les débats qui suivent. Animés, intéressants, montrant bien le pour et le contre, et puis... courtois. Personne n'y utilise un langage de gamin de maternelle...

Le critère le plus important à mon sens, l'accessibilité, n'est pas non plus si évident si l'on utilise un tableau bien construit (et non un bidule bâclé tels qu'on en voit tant...), comme j'ai pu le voir démontré de façon assez intéressante par certains webmestre dans des articles en ligne.

Sûr c'est bien plus satisfaisant de tripoter les CSS, mais comme le dit Goetter lui-même :
"attention aux fanatismes et extrêmismes démesurés car, comme partout, tout est souvent question d'interprétation et de nuances..."

Il est vrai que c'est un débât qui "râcle" loin.
Nombreux sont les webmasters qui ne veulent pas trop s'y mettent tout simplement parcequ'ils ont essayés et, je les comprend, c'est galère.
Pour l'accessibilité, il est possible de commencer par indiquer dans un tableau la balise "summary" qui doit indiquer ce que contient le tableau.
Mais bien au-delà de savoir ce qui est bien ou pas bien, c'est surtout une méthode de développement qui ira, j'en suis sûr, bien plus loin que l'utilisation de tableaux pour faire de la mise en page. Du coup, si l'on ne s'y met pas maintenant, il y aura très certainement un train à rattraper.
Alsacréation est une référence en la matière ! C'est bien de le citer. C'est mieux encore d'y aller. N'hésitez pas.

Personnellement, je suis toute conquise aux CSS pour le webdesign pur. C'est juste sur ce débat de "tables or not table" (et sur deux ou trois autres points) que je trouve que le débat a sa place.

POur ce qui est d'Alsa Creations, j'utilise plus le bouquin de Goetter (CSS 2, Pratique du design web) que le site, mais il est très pratique pour explorer les détails et dissiper les ambiguités. Il y a aussi quelques tutos de PHP très utiles pour les béotiens comme moi (comme pour faire des "style switchers" ou des "include").

Le tout CSS/HTML est sans doute l'avenir, mais un avenir qui ne sera peut-êre pas celui qu'on suppose, vu que les standards sont en mutation. Les points ambigus pourraient très bien recevoir des solutions que ne sont ni les vieux standards HTML4, ni les nouveaux points de CSS/XHTML, mais une troisième voie encore à l'étude...

Tout à fait.
Par contre, je suis persuadé que les habitudes de développement changeront, ou, au moins, évolueront. Et, je le pense sincèrement, les CSS (et tout ce qui va avec) en sont une bonne entrée en matière.

Un très bon cours sur les tableaux sur Pompage, excellent site sur les standard Web. Je vous recommande par ailleurs de jeter un oeil aux autres articles.

Quant à l'utilisation des tableaux, tout est dit au début de l'article :

Je n'ai pas dit que de faire un design en DIV était compliqué, j'ai dis que de représenter un formulaire en DIV était compliqué...

(Enfin, certains formulaire)

^^ Considérant que ca fait 2 jours que je fais QUE lire et que j'ai tappé zero ligne de code...

Merci quand même pour le lien, dommage que la gratitude que j'éprouvais envers ton aide se soit évaporée aussitôt à cause de ton manque de civisme.

Et ce tuto, ca n'est qu'un banal formulaire simple.
Je vois toujours très mal faire ce genre de truc sur un formulaire à 6 colone et 20 lignes avec des rowspan et des colspan un peu partout... de plus, float:left, ca fait sortir le champs du flux de la page... (En fait il me semble avoir lu ca quelque part hier, mais je suis pas trop certain)

Tiens, je te renvois la balle:

Puisque tu ne sais pas utiliser Google, voici un extrait de l'article fournis par Flame montrant bien que ma question à lieu de se poser quand on sort des cas de site à la "géocities"...

Extrait:
-----------------
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.
---------------



^^ et sur le formulaire que j'ai en tête, j'ai besoin d'avoir des colones de même hauteur malgré que le contenu ne soit pas de même hauteur.

(Et non, je n'en suis toujours pas revenu)

Il semble que Flamme sait beaucoup mieux se servir de Google que Galdor:

Ce qui fait que ma question est pas conne dutout.

Ps.: Merci Flamme !

On va dire que je connais les bonnes adresses...

Pour le reste...

C'est une discussion potentiellement intéressante, et j'espère bien qu'elle se poursuivra sur des bases pratiques et des arguments étayés !

En effet, ce sujet m'interesse même si je n'ai encore rien dis ^^

Pour me situer, je me placerais en plein milieu du débat étant un jeune webmaster tout frais sorti (ou presque) de ces études... Et en effet, c'est le xhtml/css qui a prit le dessus .
Pour ce qui est de l'utilisation des "tableaux", a ma connaissance, elle n'est pas vraiment bannie car pour la construction de gros formulaire ou l'affichage d'une masse de données tabulaires, cela est encore très utile... D'où le besoin de la continuité de l'évolution des normes.

NB: en parlant de tableau, ce qui m'enerve un peu, ce sont les dit "professionnels" qui utilisent à tous bouts de champs ce système pour la mise en place de leur site... Certain me disent que c'est un souci de facilité et je trouve ca bien dommage...

Pour moi tu fais un tableau html quand tu dois faire apparaître un tableau. Point

J'ai besoin d'un tableau de statistiques. Je fais un tableau, les balises table sont là pour ça.
J'ai besoin d'un formulaire. J'ai les balises form et input pour cela.
Je veux un bloc de texte contenant des paragraphes. div et p sont là...

Après même le validateur W3C te jetteras pas si tu as fait une mise en page en tableau avec une syntaxe correcte. C'est juste que si tu veux par la suite revenir sur l'aspect et l'architecture de ta page, tu vas sacrement galèrer si tu as des tr et td partout. Les apparitions, disparitions, modifications de bloc en javascript vont également risqué de poser problèmes.

L'idée est plus d'employer les outils mis à ta disposition par le html pour faire ce à quoi ils servent.

Après tu peux tout aussi bien enfoncer un coup avec un ciseaux si tu y arrives. Mais c'est pas fait pour.

Je suis de meilleure humeur maintenant (et donc je vais essayer de redevenir constructif)

En fait je vais utiliser mon approche habituelle:
Essayer de faire ca en div. Et si trop de div, trop de complication, et que je commence à avoir des commotion cérébrale à force de ma tapper la tête sur mon bureau, alors je baisse les bras et je fais en tableau.

Disons que les DIV sont chian car fat faire attention aux navigateurs qui passent dessus (et la dessus IE7 est toujours aussi bâtard).

Perso seul mon footer est un tableau car j'arrivais pas a faire ce que je voulais avec des DIV.

Tout le reste c'est DIV+CSS. C'est chian a faire, mais après ca passe nikel partout, que du bonheur.

Ou alors les tableaux. C'est facile à faire, et après ca passe nikel partout, que du bonheur.

askywhale, trolleur (mais j'ai le droit, intégrateur de maquette c'est mon gagne-pain)

ouais sauf que quant tu regarde ton code tu pleure.

Il ne s'agit pas ici de tableaux imbriqués ou autres tableaux dans lesquelles on trouve des bouts d'images découpées... Un tableau bien structuré destiné à présenter des données tabulaires est très "lisible" au niveaux du code. Si tu pleures en lisant ton code, c'est que tes tableaux sont de base mal formés.

Maintenant, la polémique est plutôt sur le point suivant : les formulaires constituent-ils oui ou non des données tabulaires ? Pour certains, oui. Pour d'autres, non. Mais le fait même qu'il y ait souvent des polémique montre qu'il est difficile d'avoir sur la question un avis tranché et que cela devrait laisser une certaine lattitude...

Il me paraît également important de retenir le point suivant : il faut s'inquiéter de la lisibilité des données quand on déconnecte le style. Une page qui se transforme en fouilli ingérable dès que l'absence de CSS lui ôte sa mise en page ne me paraît pas le summum de l'accessibilité ! De toute façon, dans l'absolu, toute page devrait être créée sans sa mise en forme, et celle-ci appliquée a posteriori. Pas le contraire...

Gni???? Et tu m'explique comment tu met du padding ou du marging sans CSS????

C'est devenue indispensable aujourd'hui

Alors moi, je suis complètement largué par ce débat.

Je vais sans doute paraître atroce aux fervents défenseurs de telle ou telle technique; mais qu'est-ce qu'on en a à foutre de savoir si tel ou tel utilise des DIV ou des tableaux ?

La question, à mon sens, ne se pose absolument pas en ces termes.
Ce que je me pose comme questions sont :
- que veux-je faire ?
- que sais-je faire ?
- qu'est ce qui me prendra le moins de temps tout en permettant aux intervenants sur le développement (dans le cas des JCLN, en général seulement moi) d'assurer la maintenance ?

Après, les questions d'ordre "éthique de la bonne programmation", c'est de la co***erie de geeks prétentieux ( provoc' trollesque). Un peu comme le genre d'arguments que j'entends parfois de la part des développeurs de mes équipes tout fraîchement sortis de l'école : "Oui, ca irait plus vite de faire comme ca et ca marcherait aussi bien; mais c'est pas propre" !!! Alors ca, ca me fait hurler ! Qui décide que telle ou telle façon de faire est "propre" ou "sale" ? Quels sont les critères ?

Je me rappelle avoir tenté de faire le premier site de G&P avec les DIV (mise en page super facile avec Dreaweaver à l'époque). Et bien Netscape 4 (encore très répandu à l'époque )n'était pas compatible.
Je me suis mis alors aux tableaux (et que c'est difficile de faire une mise en page complexe et correcte avec découpe d'image et tout i quanti avec des tableaux).
Et bien à cette époque, l'usage de ces DIV (qu'on appelait Calques je crois) était "de la sal**perie pour les nuls" dans l'esprit de bon nombre de geeks prétentieux :-) : trop facile à mettre en place à côté des tableaux ultra-complexes nécessitant des images de 1px tranparents et j'en passe sans doute.

Et oui, les avis changent mais les arguments restent :-).

Bref, je ne me laisserais certainement pas influencer sur ma façon de faire par des arguments aussi pauvres que "c'est pas propre", "c'est pas comme ca qu'il faut faire en Xtrucmachin CSS V2.3.14.12.0a" mais mes critères de choix sont l'efficacité, la productivité et la maintenabilité.

Et qu'on ne me dise pas qu'un tableau est moins maintenable que des DIV dont les positions, tailles et profondeur sont définis dans un CSS (un second fichier) au pixel prêt !!!

Voilà, ce n'était que mon avis un petit peu trollesque, je l'admets, histoire de réchauffer le forum en cet hiver qui démarre avec des températures quelque peu fraîches dans ma région du Nord ;-)

Bien sûr qu'un design soigné est une nécessité. C'est une évidence. Mais si tu n'as pas compris, cela prouve que tu ne procèdes pas à cette création de page dans l'ordre qui devrait primer : création de la page avec ses données, puis introduction des "div" et autres "span" et application de la feuille de style (qui a justement l'intérêt de pouvoir être modifiable et interchangeable).

Quand quand tu déconnectes le CSS, la page doit demeurer LISIBLE et COMPREHENSIBLE. C'est ça l'important et une page bien formée peut rester sufisemment lisible sans padding et margin. L'important est l'usage rigoureux des balises à la bonne place : des h1, h2, h3... pour les différents niveaux de titres, des listes <ul>/<li> pour les menus, des <p> à chaque paragraphe de texte... Il ne faut pas oublier qu'en XHTML/CSS, il y a a la base le XHTML, les CSS ne font pas tout !

Ce qui me fait penser que pour des données tabulaires, les tableaux ont l'intérêt de conférer de base une lisibilité aux données...

J'ai eu une fois un joueur qui avait un très vieil ordi, et il ne pouvait rien exploiter de mon site. Sûr qu'après sa refonte complète et sa réfection en XHTML/CSS, ce problème ne se présentera plus. Au pire, il aura accès à un site moche, mais les données seront exploitables. Après, c'est clair que ça ne sera pas très esthétique !

Tu vois mieux le truc, là ?

(Désolée, Kalan... Je fais sans doute partie des pinailleurs dont tu parles, mais je ne suis que modérément geek )

Je n'ai pas lu de long en large tout les postes. Pour moi la principal différence qui me ait pencher vers l'un ou l'autre c'est juste :

C'est facilement faisable en div ?
Ca n'a aucun interêt en div ?

Le div c'est bien pasque c'est très modulable (pour un design c'est pas mal donc)
Dans le cas de ton formulaire à moins que ce soit pour gagner de précieuses lignes de codes (parceque c'est un formulaire de 4000 ligne ) Je ne vois pas pourquoi ne pas utiliser de tableau si tu trouve ca plus pratique.

Et sinon pour la mise en page de formulaires tu connais les balises :
fieldset, legend, label qui donnent un bon résultat (j'ai lu ca hier sur le site du zéro je ne connaissais pas )

Bon choix

PS : Ton jeu il est bien et t'es vachement motivé

Mon avis sur le sujet :

Remplacer une mise en page de type tableau par des "div" sans plus c'est passer complètement à côté du sujet : Super on a remplacé une balise par une autre en gros, vive le progrès et le bel icône "XHTML valid" !
Le vrai enjeu derrière cette démarche c'est de donner un aspect sémantique à son code (X)HTML, la présentation étant à l a charge du CSS?
Sémantiquement un tableau (<table>) est là pour présenter des données tabulaires (et non je ne pense pas qu'un formulaire entre dans cette catégorie). Il est donc exclu (d'un point de vue du web sémantique) de l'utiliser à des fins de mise en page. Or, la balise DIV est complètement neutre ou vide du point de vue sémantique, c'est un pis-aller à n'utiliser qu'en dernier recours.
On peut (et on doit) organiser son document autour de balises à valeur sémantique comme <ul> <li> <h1> <h2> <p> <label> <fieldset> ...

Après personne n'est obligé d'aller dans ce sens, mais si on prétend faire les choses, autant les faire bien et "remplacer les tableaux par des div" c'est au mieux un raccourci de langage, au pire une preuve qu'on a rien pigé à la finalité du truc