Formulaire : Tableau ou CSS ?

Bonjour à tous...

Je débute en CSS et je tiens à remercier les webmasters ainsi que les modérateurs du forum car c'est sur votre site que j'en ai appris le plus. Une site de grande qualité (je parle du point de vue rédactionnel et non visuel ).

Ma question semble simple mais malgré toutes mes lectures, je n'ai pu y trouver de réponses simple. Quand j'ai commencé à faire des sites, on m'a dit que la meilleure présentation, pour la mise en forme des champs, pour un formulaire était le tableau. Néanmoins, je m'intéresse de plus en plus au CSS et je me demande si l'emploi de tableau simplement pour mes formulaires est une erreur.

Merci d'avance.
Modifié par Florent V. (28 Mar 2008 - 12:41)

Salut,

Personnelment j'ai toujours utilisé des tableau pour mettre en forme mes formulaires.
Cela représente un contenu tabulaire donc je ne pense pas que se soit une erreur d'utiliser des tableau de cette maniere ci.

Néanmoin tu peut tout de meme utiliser les div, pour faire des mise en forme un peu spéciale point de vu graphique.

Voila tout depend de ce que tu veut faire

++

Bonjour

ne pas aborder cette question en termes de "oui/non" et de "réponses simples". La poser en revanche dans un contexte donné.

Le tableau de présentation d'un formulaire ne se différencie en rien d'un autre tableau de présentation : il est à éviter sur le principe, mais il peut être préférable à un bricolage CSS selon tes compétences ou la possibilité de réaliser tel ou tel effet de présentation en CSS.

Dans tous les cas, avec ou sans tableau, ce n'est pas déterminant : les contraintes de structuration correctes et accessibles des éléments de formulaires sont identiques. Et celles d'un tableau de données resteront, le cas échéant, celles d'un tableau de données.

Concrètement:
* utiliser LABEL FOR pour les étiquettes de formulaires, ou le TITLE des champs, et LEGEND/FIELDSET si nécessaire, avec ou sans tableau.
* s'assurer que le rendu tableau reste compréhensible une fois linéarisé.
* ne pas utiliser d'éléments typiques des tableaux de données (th, scope, caption, summary)
Modifié par Laurent Denis (28 Mar 2008 - 11:43)

FunK a écrit :

Cela représente un contenu tabulaire

énorme sottise, comme à chaque fois qu'on pense en terme de "données" ou de "contenu" pour un tableau. Qu'il s'agisse de ce qu'on a l'habitude d'appeler en HTML un tableau de données ou un tableau de mise en forme, ce n'est qu'un mode de représentation, pas un contenu spécifique (Sur le principe, ce serait possible, mais pas en (X)HTML).

Un tableau, c'est une disposition visuelle où des en-têtes donnent leur sens à des lignes et des colonnes de cellules qui leur sont associées. Un formulaire, ce sont des champs et parfois des regroupements de champs dotés d'étiquettes (métadonnées), sans disposition visuelle spécifique (les étiquettes peuvent ne pas être visibles, d'ailleurs). Un formulaire n'est pas une représentation graphique de relations entre des données. Un tableau, si (c'est ce qui le caractérise). Le plus proche cousin du tableau de données ou de présentation, c'est l'image MAP.

Les conflits insolvables sur les applicatifs Web où interviennent des traitements de données en tableau en sont d'ailleurs un excellent exemple (on ne peut pas mettre un <form> autour d'un <tr>, etc.)
Modifié par Laurent Denis (28 Mar 2008 - 12:40)

J'ai bien compris ce que tu me disais, mais ne parle pas de mon niveau. Même si la solution proposée est assez compliqué, c'est à moi de me mettre au niveau.

Je ne veux pas relancer le débat que j'ai déjà retrouvé sur divers forum où les habitués tente de convaincre les autres que le CSS c'est le bien et les tableaux le mal. Je souhaite juste savoir pour ce cas de figure, ce qui serait le mieux, en quoi l'utilisation de tableau pose problème dans ce cas.

Merci

Enhide a écrit :
en quoi l'utilisation de tableau pose problème dans ce cas.

Aucun problème propre aux formulaires, alors, sous réserve de leur emploi correct. Mais sans tableau de présentation, c'est réputé mieux.

Te voilà bien avancé, n'est-ce pas ?
Modifié par Laurent Denis (28 Mar 2008 - 14:25)

Laurent Denis a écrit :


Te voilà bien avancé, n'est-ce pas ?

Oui, c'est vrai.... Néanmoins, selon le choix que je ferai maintenant, je pourrai quand même apporter une justification.

Merci
Modifié par Enhide (28 Mar 2008 - 14:31)

Enhide a écrit :
J'ai bien compris ce que tu me disais, mais ne parle pas de mon niveau. Même si la solution proposée est assez compliqué, c'est à moi de me mettre au niveau.

Je ne veux pas relancer le débat que j'ai déjà retrouvé sur divers forum où les habitués tente de convaincre les autres que le CSS c'est le bien et les tableaux le mal. Je souhaite juste savoir pour ce cas de figure, ce qui serait le mieux, en quoi l'utilisation de tableau pose problème dans ce cas.

Utilisations des balises table et balises liées ne sont pas opposées à l'utilisation de CSS. Les mettre en position d'antagonistes est donc une erreur.
D'ailleurs quelque soit le CSS utilisé, il n'a pas de sens sans balises...

Dire que le CSS c'est bien et les tableaux c'est mal est un conseil de l'ordre du : Les fraises c'est bon, le chocolat c'est pas bon.

Derrière les balises HTML et leur utilisation se cache une manière de donner un sens au contenu. Par exemple, on utilise une balise <hn> pour représenter un titre, action qui visuellement a peu d'interêt, mais va permettre aux programmes (navigateurs, lecteurs d'ecran, crawlers, etc...) qui doivent analyser les différents éléments d'un contenu pour savoir ce qu'ils sont... et bien de savoir ce qu'ils sont... héhé

Pour les <table> c'est pareil :

Laurent Denis a écrit :
Un tableau, c'est une disposition visuelle où des en-têtes donnent leur sens à des lignes et des colonnes de cellules qui leur sont associées. Un formulaire, ce sont des champs et parfois des regroupements de champs dotés d'étiquettes (métadonnées), sans disposition visuelle spécifique (les étiquettes peuvent ne pas être visibles, d'ailleurs). Un formulaire n'est pas une représentation graphique de relations entre des données.

Inutile de reformuler ce qui est si bien dit...

D'ailleurs, on peut très bien représenter des données tabulaires avec uniquement des <div> mais les données perdent de leur sens...

a écrit :
Je souhaite juste savoir pour ce cas de figure, ce qui serait le mieux, en quoi l'utilisation de tableau pose problème dans ce cas.

Je pense que ce qu'à voulu dire Laurent Denis concernant ton interrogation est que, si tu ne sais pas faire autrement, utiliser un tableau est mieux que de bidouiller avec d'autres balises et du CSS pour obtenir un résultat bancale. Si tu as le choix d'un point de vue technicité, préférer ne pas utiliser de tableau...

edit : Désolé j'ai un peu l'impression de répéter du déjà dit...

Et les fraises c'est moins sucré et moins gras que le chocolat...
Modifié par skywalk3r (28 Mar 2008 - 14:38)

skywalk3r a écrit :
.

Et les fraises c'est moins sucré et moins gras que le chocolat...

Oui, mais le coulis de fraises aux pépites de chocolat...

Merci à tous pour ces explications.

De tout façon, je suis en train de m'y mettre sérieusement : php, html, css..... vous allez me revoir !

Pour moi se sera fraises avec chantilly !
Modifié par Enhide (28 Mar 2008 - 14:40)

Laurent Denis a écrit :

Oui, mais le coulis de fraises aux pépites de chocolat...

C'est un peu comme un <table> dans un <fieldset>, faut pas en abuser

skywalk3r a écrit :


C'est un peu comme un <table> dans un <fieldset>, faut pas en abuser

J'aurais plutôt dit un code dans un pre (HTML5, d'ailleurs), ou un dfn dans un dt, voir un <em><em>...</em></em> à la place d'un <strong>...</strong>. Une affaire de gourmets.

Laurent Denis a écrit :


J'aurais plutôt dit un code dans un pre (HTML5, d'ailleurs), ou un dfn dans un dt, voir un <em><em>...</em></em> à la place d'un <strong>...</strong>. Une affaire de gourmets.

Je suis un vrai gourmet.... mais je n'ai quand même rien compris à ce que tu viens de dire....

Enhide a écrit :



Je suis un vrai gourmet.... mais je n'ai quand même rien compris à ce que tu viens de dire....

* pre (le chocolat) définit un texte préformatté, pas un extrait de code, contrairement à code (la fraise). Donc les bouts de code devraient être balisés avec les deux.
* dt (le chocolat) indique le terme décrit, mais il est souvent plus précisément l'instance d'une définition, ce que décrit dfn (la fraise)... once again, donc, quand c'est le cas.
* strong est une grossièreté inutile qui tente maladroitement de différencier arbitrairement un second niveau d'emphase là où il s'agit d'une graduation. em et strong sont tous deux la fraise ou chocolat, comme on voudra. Mais pour le coulis aux pépites, un gourmet soutiendra l'usage de em em pour un niveau d'emphase suppérieur à em...

Après, on peut aussi aborder cite au dessert

<edit>Faut-il préciser que ces argucies de sémantique n'ont actuellement absolument aucun impact pratique, en dehors de l'amusement qu'elles procurent, et des réflexions qu'elles suggèrent ?</>
Modifié par Laurent Denis (28 Mar 2008 - 15:28)

Laurent Denis a écrit :


<edit>Faut-il préciser que ces arguties de sémantique n'ont actuellement absolument aucun impact pratique, en dehors de l'amusement qu'elles procurent, et des réflexions qu'elles suggèrent ?</>

Sur ce point, laisses moi ne pas être totalement d'accord, et je m'en vais t'expliquer le pourquoi.

Je suis étudiant en Service et Réseaux de Communication à l'IUT de béziers, actuellement en période de stage. Tout ce passe bien, l'entreprise est géniale. Néanmoins, que se soit dans ma poursuite d'étude ou dans mon objectif professionnel, je privilégies l'aspect communication sur les aspects réseau et programmation web. Mais je souhaite également évoluer rapidement vers une fonction de chef de projet, et c'est dans cette optique que j'ai choisi un stage où on me propose de mener un projet à terme seul et ainsi d'aborder tout les aspects de ce secteur qui m'intéressent.

Le problème se situe au niveau du planning habituel d'un tel projet, on commence par coder.... donc je suis dans la panade. mais la suite viendra dès que j'aurai fini de coder, j'irai rejoindre les chargés de communication, de relation client, les graphistes et les commerciaux.

Donc ma situation : à 8 dans un bureau à coder alors que je suis un peu nul, donc la moindre distraction est la bien venue ! !

Sinon je ne mentais pas quand je disais que je commençais presque à y prendre goût.
Modifié par Enhide (28 Mar 2008 - 17:57)

Enhide a écrit :

Sinon je ne mentais pas quand je disais que je commençais presque à y prendre goût.

Un petit chocolat pour accompagner le café, alors: des 5 éléments considérés traditionnellement comme caractéristiques d'un tableau de données et proscrits dans un tableau de présentation, 3 n'en sont en réalité pas.

Lesquels ?

Hmm... thead, tbody et tfoot?

Oui (comme ils sont 3 sur 5, c'est assez évident), mais pourquoi ? Et où est-ce pas si simple à trancher ?

Question subsidaire mais essentielle: en quoi est-ce éventuellement important. Ou pas.
Modifié par Laurent Denis (30 Mar 2008 - 10:44)

Hmm... est-ce que ça a un lien avec le fait que thead et tfoot sont en fait la transposition d'une pratique de l'imprimé (répéter certains éléments du tableau sur chaque page)?
Pour le reste je donne ma langue au chat.