Emploi de <p> ou <div> pour les éléments d'un formulaire

Bonjour à tous.

Voilà une question (simple) le taraude l'esprit.
Je vois de plus en plus que l'élément <p> est utilité pour encadré les lignes d'un formulaire ex :

<p>
<label for="nom">Nom :</label>
<input type="texte" id="nom" name="nom" value="" />
</p>

Jusqu'ici j'utilise des <div> pour le faire...

Ma question est simple : Niveau sémantique peut ont dire que chaque ligne d'un formulaire est un paragraphe ?? J'ai des doutes..

Un paragraphe ne sous entends pas qu'il s'agit de texte, phrases, ect....

Merci d'éclairer ma lanterne .

Bonne journée.
Modifié par ernstein (04 Jul 2009 - 11:26)

Salut,

Non, ce n'est absolument pas un paragraphe et un <p> n'a donc rien à faire ici.

Certains (en général débutants) pensent en effet que les <div> sont faites pour délimiter les grandes sections (header, footer, sidebar, etc.) et les <p> les courtes. C'est bien sûr totalement farfelu .

Ben effectivement ça reste mon point de vue... Mais je reste quand même étonné, j'ai vu ce genre de balisage sur des sites sérieux traitant des standards .....

ça ouvre le doute.

Hello,

les éléments HTML étant (pour l'instant) très limités il faut bien faire avec ce qu'on a... et du coup cela implique AMHA d'élargir le champ d'utilisation de tel ou tel élément. Par exemple l'utilisation de UL/LI/A pour un menu est assez discutable mais cela me semble un bon compromis en attendant de pouvoir utiliser l'élément HTML5 NAV.

De la même façon et en attendant l'élément HTML5 MENU (<edit>ah ben non : après lecture de différents articles il semble que MENU ne serve pas à ça</edit) je trouve que P est un bon compromis. Il ne s'agit peut-être pas d'un "vrai" paragraphe mais on retrouve quand même une notion de "section" dont chacune est reliée aux autres.

On peut bien sûr préférer DIV (que je trouve personnellement trop neutre dans ce cas précis), l'utilisation de BR (qui ne simplifie pas la mise en forme du formulaire) ou pourquoi pas une liste...
Modifié par Heyoan (04 Jul 2009 - 14:10)

C'est intéressant d'intégrer la liste à la réflexion puisque au final c'est bien une liste d'éléments non ordonnés ....

Tiens puisque HTML 5 est dans l'actu, du coté des formulaires, y'a t-il de grandes avancés à en attendre ?

Quelques chose du genre

<form>
<fieldset>
<legend></legend>
<form_item>
    <label />
    <input />
</form_item>
</fieldset>
</form>

?

ernstein a écrit :
Tiens puisque HTML 5 est dans l'actu, du coté des formulaires, y'a t-il de grandes avancés à en attendre ?

Oui : voir les specs (patience : la page est longue à charger).

Notamment : beaucoup de nouveaux types (date, email, number, url, ...) et d'attributs (required, form, autofocus, replace, ...) pour les éléments INPUT.

Voir également HTML 5 differences from HTML 4 (ou la traduction).

Voilà qui donne envi que le temps passe
Merci
A+

Salut Felipe, Heyoan,

Felipe a écrit :
- y a rien de prévu particulièrement pour ça

Heyoan a écrit :
les éléments HTML étant (pour l'instant) très limités il faut bien faire avec ce qu'on a... et du coup cela implique AMHA d'élargir le champ d'utilisation de tel ou tel élément.

Vu qu'il n'y a pas de tag spécifique, les label-input de ernstein seront simplement des divisions génériques, et je crois que ça suffit amplement ici. Où est la nécessité de qualifier sémantiquement ces divisions de fieldset ?

Felipe a écrit :
on saisit du texte donc pourquoi pas un paragraphe?

Parce qu'il ne suffit pas que ce soit du texte pour que ce soit un paragraphe (voir point suivant).

Felipe a écrit :
si je devais réafficher les données une fois saisies et traitées, ce serait sous la forme
<p>Nom : Albanel</p>
<p>Fonction : aucune</p>

Heyoan a écrit :
l'utilisation de UL/LI/A pour un menu est assez discutable

Felipe, ce que tu entends par paragraphe n'est pas ce que j'entends moi (d'où le troll ). À mon sens, tes deux lignes ne sont pas des paragraphes, mais (au mieux) de bons vieux éléments de liste.
Heyoan, même chose, je trouve que sémantiquement, une table des matières (donc un menu de site) est très bien balisée avec des <li>.

Il ne s'agit, bien sûr et encore une fois, que de mon interprétation très personnelle, et il pourrait difficilement en être autrement vu que, de toutes façons, le "paragraphe" n'est pas défini dans les specs. Et puis franchement, j'en parle parce que j'aime bien les questions théoriques, mais il faut bien reconnaître l'importance très relative du machin...

C'est vrai que cette histoire de liste d'élément semble au final une piste...

Bon ce que je cherchais à vrai dire c'était de savoir si je ne passais pas à coté de quelques chose d'important...

Merci à vous pour vos retours.

marcv a écrit :
Vu qu'il n'y a pas de tag spécifique, les label-input de ernstein seront simplement des divisions génériques, et je crois que ça suffit amplement ici. Où est la nécessité de qualifier sémantiquement ces divisions de fieldset ?
...
Il ne s'agit, bien sûr et encore une fois, que de mon interprétation très personnelle, et il pourrait difficilement en être autrement vu que, de toutes façons, le "paragraphe" n'est pas défini dans les specs.

Euh... je n'ai pas bien compris ce que tu voulais dire par "ces divisions de fieldset". En tout cas je suis d'accord avec toi pour dire qu'il n'y a pas de nécessité mais il me semble tout de même logique d'avoir une séparation nette entre les différentes commandes d'un formulaire et ce avec ou sans CSS. Je ne reviens pas sur ce que je disais plus haut de BR et de DIV et pour ce qui est des specs de P il n'est effectivement fait mention que de "paragraphe" : en me basant sur différentes définitions de ce terme (et en jouant un peu sur les mots pour l'adapter au web comme on le fait généralement en décrétant qu'un menu de navigation correspond à une liste de liens ) je dirais tout simplement qu'il s'agit d'une "subdivision de texte". Et hop ! Hocus Pocus ! Voilà qui va parfaitement bien pour séparer mes commandes !

Cela dit je trouve qu'un élément tel que FORM_ITEM comme suggéré par ernstein serait le bienvenu, de même que le NAV prévu par HTML 5 sera tout de même mieux que l'utilisation d'une liste et, plus généralement, que chaque nouvel élément qui est spécifiquement dédié à un usage me paraît être une bonne chose.

a écrit :
en jouant un peu sur les mots pour l'adapter au web comme on le fait généralement en décrétant qu'un menu de navigation correspond à une liste de liens langue ) je dirais tout simplement qu'il s'agit d'une "subdivision de texte"

Pour le menu de navigation en <li>, tu sais déjà que je trouve cela parfaitement correct. Et pour le reste, il me faudrait vraiment beaucoup jouer sur les mots pour arriver à considérer qu'un formulaire est un texte ! (et que ses subdivisions sont des paragraphes, par voie de conséquence).

a écrit :
il n'y a pas de nécessité mais il me semble tout de même logique d'avoir une séparation

La nécessité sur laquelle je m'interroge n'est pas celle de séparer, sur laquelle nous sommes bien naturellement d'accord, mais celle de qualifier sémantiquement ces séparations. Une div indique une division. Ça me semble amplement suffisant dans le cas qui nous intéresse, et perso je m'arrête là, parfaitement satisfait de ma balise. Pourquoi vouloir aller plus loin, et ajouter, au prix de contorsions sémantiques assumées, qu'en plus d'être des divisions, ce sont les divisions d'un texte ?

Disclaimer : Je le répète, il s'agit pour moi d'une discussion purement théorique. Au final que l'on mette un p, une div ou des li, cela n'a pas vraiment d'importance. Je trouve la sémantique intéressante sur le principe et j'aime en discuter pour le plaisir, mais concrètement, ce n'est pas la nature des divisions de mon fieldset qui va changer la face de mon site

marcv a écrit :
Pour le menu de navigation en <li>, tu sais déjà que je trouve cela parfaitement correct.

Moi aussi... en attendant mieux.

marcv a écrit :
Et pour le reste, il me faudrait vraiment beaucoup jouer sur les mots pour arriver à considérer qu'un formulaire est un texte ! (et que ses subdivisions sont des paragraphes, par voie de conséquence).

Comme je disais dans mon premier post en l'état actuel des choses et vu le manque d'éléments spécifiques on est obligé de faire au "plus juste" et du coup cela devient très subjectif. Pour ma part, si un élément en particulier n'existe pas, ça ne me semble pas logique d'utiliser un DIV quand je peux utiliser un P (en gros quand les éléments qu'il contient sont tous de type en-ligne). Je me rends bien compte en le disant que c'est tout sauf objectif mais bon !

marcv a écrit :
La nécessité sur laquelle je m'interroge [...est...] celle de qualifier sémantiquement ces séparations.

Arf ! J'ai copié / collé ton texte mais j'ai oublié sémantiquement. Donc je suis d'accord avec toi... dans l'état actuel des choses. Cela dit ce sera bien mieux quand l'élément qui va bien existera et il se trouve que du coup on aura non seulement une séparation claire des commandes du formulaire mais qu'en plus on aura en bonus la sémantique qui va avec.

marcv a écrit :
Disclaimer : Je le répète, il s'agit pour moi d'une discussion purement théorique.

Ben tout pareil ! D'ailleurs quand tous les éléments existeront je serai tout triste de ne plus me poser ce genre de questions existentielles !

Plop,

http://www.assemblesoft.com/examples/form/simpleform.html est pertinent pour la question de la verbosité pénible des LEGEND superflus ou trop longs. Mais en partie erroné sur la difficulté de styler LEGEND (dans un SPAN, ça va tout de suite mieux) et surtout incomplet en ne parlant pas du rôle de TITLE pour se substituer au couple LEGEND/LABEL d'un champ de formulaire.

Sinon, P ou DIV autour du couple LABEL INPUT, aucune différence à aucun point de vue, à commencer par l'accessibilité ou la sémantique, sauf sur un détail de rendu : P a un rendu par défaut plus sympa avec les seuls styles du navigateurs, en raison de ses marges verticales.

marcv a écrit :
Non, ce n'est absolument pas un paragraphe et un <p> n'a donc rien à faire ici.

Mais bien sûr. Tu as une définition exacte du paragraphe en HTML?
Je vais faire la réponse à la question pour qu'on aille plus vite:
- HTML 4 dit «P représente un paragraphe», et ne définit pas la notion de «paragraphe».
- HTML 5 dit «P représente un paragraphe», et définit la notion de paragraphe ainsi:

a écrit :
A paragraph is typically a block of text with one or more sentences that discuss a particular topic, as in typography, but can also be used for more general thematic grouping. For instance, an address is also a paragraph, as is a part of a form, a byline, or a stanza in a poem.

Donc, si je résume: HTML 4 n'exclut pas l'usage que tu décries, et HTML 5 (version de travail) le cite comme un des quelques exemples typiques d'usage de l'élément P. Game over?

marcv a écrit :
Certains (en général débutants) pensent en effet que les <div> sont faites pour délimiter les grandes sections (header, footer, sidebar, etc.) et les <p> les courtes. C'est bien sûr totalement farfelu .

Ravi d'apprendre que je suis un débutant farfelu.

Pour être un peu précis:
- DIV est un conteneur générique que l'on utilise pour un peu ce qu'on veut si on le souhaite.
- P est un conteneur un poil moins générique (mais très générique tout de même), que l'on limitera à des contenus relativement courts du fait de la restriction sur les éléments de type bloc.
- DIV n'est pas «fait» pour délimiter les grandes sections, et P les courtes (un paragraphe n'est d'ailleurs généralement pas une section au sens de XHTML2/HTML5, pas plus que nombres de DIV dessinant la charpente d'un document). Cela reste cependant un usage tout à fait acceptable (avec une définition large de «section», qui ne correspond pas à SECTION dans HTML5), que j'ai tendance à conseiller aux débutants car cela permet un arbitrage plus facile dans l'usage de ces deux éléments, sans conséquences néfastes à ma connaissance. (Et aussi parce que dans les cas où cela amène à utiliser P plutôt que DIV on a généralement intérêt, pour un rendu avec les seules styles du navigateur, à bénéficier des marges par défaut des paragraphes.)

Je suis ouvert à la critique s'il y a des raisons concrètes de déconseiller cet usage.
Modifié par Florent V. (05 Jul 2009 - 18:49)

marcv a écrit :
il me faudrait vraiment beaucoup jouer sur les mots pour arriver à considérer qu'un formulaire est un texte !

Face à ce genre de déclaration, un prof de lettres opinera du chef, tandis qu'un typographe lèvera les yeux au ciel.

Salut Laurent, Florent,

a écrit :
aucune différence à aucun point de vue, à commencer par [...] la sémantique

Mais encore... ?

a écrit :
HTML 4 n'exclut pas l'usage que tu décries [...] Game over?

Non, pas vraiment. Ici comme ailleurs, je me garderais bien de considérer une absence de désaccord explicite comme un accord implicite . La définition de paragraphe n'est pas donnée, cela ne signifie pas "Faites-en ce que vous voulez". Je pense que le fait que cela ne soit pas défini expressément signifie simplement que l'acception courante s'applique.

Je regrette entre parenthèses ton "Game over? " car mon intervention n'avait absolument pas pour objectif de "gagner la partie" sur Felipe ou Heyoan. Je ne pensais pas avoir donné l'impression de contredire gratuitement, dans le seul but d'avoir raison au final. Visiblement ça a pourtant été perçu ainsi et je le déplore.

a écrit :
HTML 5 (version de travail) le cite comme un des quelques exemples typiques d'usage de l'élément P. Game over?

C'est un très bon point. Ma réponse à Ernstein se basait sur le HTML tel que je le connais et l'ai toujours connu. Ne connaissant pas la draft de HTML5 dans les détails, je n'avais pas connaissance de cette définition dans la prochaine version du langage, mais suis maintenant, tu t'en doutes, en désaccord complet avec la partie "part of a form" (nul besoin de réexpliquer pourquoi ). Il s'agit exactement du même type de désaccord que j'ai par exemple avec les specs actuelles quant à l'utilisation des listes de définition pour marquer des dialogues. Bref, au sens strictement sémantique (et c'est là encore très personnel), je ne pense pas qu'il soit bienvenu d'appeler paragraphe un élément qui s'écarte en certains aspects du sens communément admis pour ce mot.

En tout cas, je pense que cette définition "officielle" répond parfaitement à la question de Ernstein : à partir du HTML5, utiliser les <p> pour baliser les label-input est bien parti pour être la méthode standard.

a écrit :
Ravi d'apprendre que je suis un débutant farfelu.

J'ai dit "en général". Donc dans ton cas, débutant non, mais farfelu... peut-être

a écrit :
j'ai tendance à conseiller aux débutants car cela permet un arbitrage plus facile [...] sans conséquences néfastes [et aussi pour] bénéficier des marges par défaut

Cela me semble très bien, et même si personnellement je ne procède pas de cette manière, il n'y a là pour moi aucune hérésie. Je crois avoir précisé dans mes deux dernières interventions que je ne vois pas, dans la pratique de réelle importance à cette histoire. La question de Ernstein était purement sémantique, ma réponse l'était aussi.
Modifié par marcv (05 Jul 2009 - 20:46)

Hello Florent

juste pour revenir sur un détail.. qui à mon sens n'en ai pas un

a écrit :

Mais bien sûr. Tu as une définition exacte du paragraphe en HTML?
Je vais faire la réponse à la question pour qu'on aille plus vite:
- HTML 4 dit «P représente un paragraphe», et ne définit pas la notion de «paragraphe».
- HTML 5 dit «P représente un paragraphe», et définit la notion de paragraphe ainsi:

A paragraph is typically a block of text with one or more sentences that discuss a particular topic, as in typography, but can also be used for more general thematic grouping. For instance, an address is also a paragraph, as is a part of a form, a byline, or a stanza in a poem.

y'a un moment ou à mon sens il faut lâcher les bouquins.

Que ce soit pour du HTML ou n'importe quoi d'autres.. Un paragraphe est un paragraphe.. avec des morts de verbes... ect...

Le fait que nous décidions d'employé ce terme au niveau de la sémantique HTML est justement une adaptation de ce qu'il est dans le monde de l'écrit. Celui là même qui lui a donné naissance. Donc pour le coup il n'y à pas la moindre raison que ce que nous appelons depuis la nuit des temps un paragraphe change de signification entre HTML je ne sais quoi et HTML tralala... Ce terme à justement été employé pour ce qu'il représente sémantiquement.

C'est un paragraphe....

Du coup en terme purement descriptif je ne vois pas en quoi un champs de formulaire à de rapport avec un mot, un verbes ou un signe de ponctuation...

ernstein a écrit :
y'a un moment ou à mon sens il faut lâcher les bouquins.

Que ce soit pour du HTML ou n'importe quoi d'autres.. Un paragraphe est un paragraphe.. avec des morts de verbes... ect...

Le fait que nous décidions d'employé ce terme au niveau de la sémantique HTML est justement une adaptation de ce qu'il est dans le monde de l'écrit. Celui là même qui lui a donné naissance. Donc pour le coup il n'y à pas la moindre raison que ce que nous appelons depuis la nuit des temps un paragraphe change de signification entre HTML je ne sais quoi et HTML tralala... Ce terme à justement été employé pour ce qu'il représente sémantiquement.

C'est un paragraphe....

Du coup en terme purement descriptif je ne vois pas en quoi un champs de formulaire à de rapport avec un mot, un verbes ou un signe de ponctuation...

Ben pas d'accord : les spécifications HTML évoluent et s'adaptent et il faut au contraire ne pas lâcher les bouquins. . Qu'un terme précis ait été choisi au début pour un élément HTML est une chose mais ça n'oblige en rien à limiter l'emploi de cet élément à sons sens courant. C'est comme si tu disais "une division est une division et basta"... sauf qu'une division au sens HTML ne décrit pas la même chose qu'une division dans le vocabulaire courant.
Modifié par Heyoan (05 Jul 2009 - 21:35)