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

(reprise du message précédent)

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)

Non mais tu m'aura compris Heyoan quand je dis qu'il faut lâcher les bouquins, je sous entends juste que pour cette exemple et à mon sens le <p> paragraphe HTML sémantiquement à du sens pour décrire les éléments constitutifs d'un texte... et je ne vois pas trop pourquoi d'un seul coup il en serait autrement... m'enfin.. c'est intéressant tous ces points de vues. Comme quoi la question n'était pas si nulle.

Heyoan a écrit :
(...) sauf qu'une division au sens HTML ne décrit pas la même chose qu'une division dans le vocabulaire courant.

XHTML2, combien de divisions ?

(oui je sais, tirer sur une ambulance ou un corbillard, ça ne se fait pas )
Modifié par Felipe (05 Jul 2009 - 23:20)

ernstein a écrit :
à mon sens le <p> paragraphe HTML sémantiquement à du sens pour décrire les éléments constitutifs d'un texte...

Je ne vais pas faire le chieur de service et te demander de définir la notion de «texte», ça serait mesquin.

Un peu plus intéressant, on pourrait parler de la différence entre un contenu textuel dans une page web et les différents éléments d'interface (navigation diverses, formulaire de recherche), et les éléments qui tiennent un peu des deux (un aperçu de contenus connexes avec un extrait, est-ce de la navigation-interface ou du texte-contenu?). Et formuler alors la question du formulaire ainsi: est-ce un contenu ou un élément d'interface? Et si ce formulaire était un simple PDF (non réactif) à imprimer, serait-ce un contenu? Et si j'ai deux bouts de texte explicatifs au sein de mon formulaire, dois-je baliser en <P> alors que je ne suis pas dans un contenu qui jusqu'ici a mérité d'être paragraphé?

Mais pour ne pas trop me répéter, je vais indiquer ce message qui a déjà près de deux ans (comme le temps passe!):
http://forum.alsacreations.com/topic-2-29625-1-ResoluBalise-paragraphe.html#p224171
Modifié par Florent V. (06 Jul 2009 - 00:25)

Mangez du Transitional, c'est du bon.

<!-- single column list (DEPRECATED) --> 
<!ELEMENT menu (li)+>
<!ATTLIST menu
  %attrs;
  compact     (compact)     #IMPLIED
  >

Comme on peut le voir, il est déprécié et n'est plus recommandé en Strict, donc l'alternative est bien une liste non ordonnée.


En ce qui concerne l'usage de <p> pour la séparation des éléments du formulaire, je suis de l'avis de Florent V.
Bruno Bichet avait fait un article similaire, mais concernant l'utilisation du <p> pour des micro-contenus :
http://www.css4design.com/blog/marquage-html-des-micro-contenus-p-div-ou-bien

a écrit :
Ben pas d'accord : les spécifications HTML évoluent et s'adaptent et il faut au contraire ne pas lâcher les bouquins. langue . 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.

Nan mais dans ces cas là, on va gentillement attendre que le w3c nous propose une balise plus en rapport (ce qui est visiblement déjà fait, de toutes façons...).
Je ne vois pas pourquoi on devrait modifier le sens du mot "paragraphe" pour qu'il corresponde mieux à nos besoins en HTML.
Il y a des failles dans la sémantique web, c'est un fait, on en est tous d'accord.

Mais au même titre qu'un <table> doit désigner un tableau de données, un <p> doit désigner un paragraphe.
Je veux bien qu'on modifie le sens du mot "tableau de données" si on modifie le sens du mot "paragraphe". Mais... ça me dérangerai un petit peu quand même.

Utiliser un <p> pour autre chose qu'un paragraphe revient typiquement au même que d'utiliser des <table> pour la structure de page, non ? Enfin je le vois comme ça...

Un "div" ou un "ul-li", est à mon humble avis dans ce cas précis sémantiquement un peu plus correct, et... Quel souci cela pose-t-il ?
Modifié par Nigel (06 Jul 2009 - 14:09)

Nigel a écrit :
Un "div" ou un "ul-li", est à mon humble avis dans ce cas précis sémantiquement un peu plus correct, et... Quel souci cela pose-t-il ?

Un div, pas grand chose. Une liste .... T'es-tu déjà demandé à quoi ressemblait ton site sans aucun style CSS ? Imagine-le (ou visualise-le simplement grâce à l'extension Webdeveloper Toolbar de Firefox) et penses-tu qu'il est correct de voir une liste de champs précédés de puces ? Pas si sûr.

Nigel a écrit :
Mais au même titre qu'un <table> doit désigner un tableau de données, un <p> doit désigner un paragraphe.

Oui. Mais non. Le HTML n'est pas assez fourni en balises pour se permettre de ne désigner une balise que pour un seul type de contenu. Il faut donc en détourner l'usage sémantique au sens littéraire du terme pour essayer de combler le vide sémantique au sens Web du terme.

Mais je crois qu'on entre dans un débat inutile et éternel.

ernstein a écrit :
Que ce soit pour du HTML ou n'importe quoi d'autres.. Un paragraphe est un paragraphe.. avec des morts de verbes...
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...
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...

Ça vient de où cette manie de vouloir établir des parallèles et comparaisons là où il n'y a pas lieu d'en faire ? Les règles de l'imprimerie et celles du numériques ne relèvent pas du tout du même registre. Les langages (parlés, écrits, informatiques, gestuels, etc.) ont leurs sémantiques propres, plus ou moins puissantes et plus ou moins efficaces. HTML n'a pas plus à voir avec l'imprimé qu'avec un dialecte local ou un langage des signes pour les sourds-muets. Chercher à appliquer à l'un les principes de l'autre ne mène strictement nulle part.

P n'a rien à voir avec un paragraphe imprimé : il décrit que ce qu'il contient est du texte (sous une forme ou sous une autre, pas nécessairement calibré en "paragraphes"...) Une seule ligne, deux simples mots suffisent à le requérir comme balise porteuse cohérente.
FORM + ses balises ont déjà signalé qu'il s'agit d'un formulaire. Reste juste à préciser que ce formulaire se présente sous forme textuelle, et pour ça P est très bien. C'est peut-être pas parfait mais ça remplit son rôle, et on n'en demande pas plus dans l'état actuel de l'art.
Comme il se trouve qu'il y a justement des textes dans le formulaire (que ce soient des labels, des infos ou même le type de contenu à entrer) la question se résoud toute seule.

Nigel a écrit :
Utiliser un <p> pour autre chose qu'un paragraphe revient typiquement au même que d'utiliser des <table> pour la structure de page, non ?

Dans la mesure où ni l'un ni l'autre n'est problématique? Parfaitement.

Nigel a écrit :
sémantiquement un peu plus correct

Un DIV sera équivalent à un P au niveau du rendu de l'information dans un lecteur d'écran. Il sera ignoré au même titre qu'un P par un navigateur (s'il s'agit d'en retirer une information exploitable dans une interface particulière) ou un moteur d'indexation car trop générique. Donc ton DIV sera sémantiquement tout aussi correct qu'un P. Mais pas «plus».

Une liste peut être correcte, mais ça risque de donner un rendu relativement pénible avec un lecteur d'écran, car ça donne une certaine surcharge d'information. Donc je dirais que c'est moins bien.

Pour la question «paragraphe = des phrases» (quoi qu'en dise HTML 5 qui serait une perversion du démon), voir la réponse d'Arsène à la quelle je souscris entièrement.

Quant à l'imperfection sémantique de HTML, ce n'est vraiment pas sur ce genre de choses qu'elle se manifeste. (Une piste: les applications web; une solution: ARIA. Une autre piste: les contenus riches; une solution: euh...).
Modifié par Florent V. (06 Jul 2009 - 15:04)

Agylus a écrit :
T'es-tu déjà demandé à quoi ressemblait ton site sans aucun style CSS ? Imagine-le (ou visualise-le simplement grâce à l'extension Webdeveloper Toolbar de Firefox)

Dans Firefox, sans extension:
«Affichage > Style de la page > Aucun style»

J'admets ne pas avoir bien réfléchi sur le coup du ul-li. d'autant plus que je ne pratique quasiment jamais cette solution, à moins d'y être forcé à cause de l'utilisation d'un framework CSS "propriétaire". (c'est d'ailleurs très à la mode, ces ul li dans une liste de champs. oups, j'ai utilisé le terme "liste")
D'un autre côté... Ce n'est pas aberrant non plus qu'il y ait une puce de liste avant un couple de champs (label + champs de saisie + bouton), tout dépends des cas. On ne va tout de même pas généraliser.

Ceci dit, si l'utilisation d'un <p> ne sert qu'à ajouter une marge en bas de chaque groupe de champs, je pense qu'on s'en va justement vers un lieu où nous n'avons plus lieu d'aller.
De plus, n'oublions pas le "fieldset"...

Le div, à mon humble avis, est justement là pour ça. Diviser des éléments dans des groupes sans pour autant leur donner une valeur sémantique autre que "vous faites partie du même groupe". Et, il me semble que c'est ici le but recherché...
Pourquoi donner une valeur sémantique "paragraphe" à un groupe de champs de formulaires ?
Je n'en vois pas la raison.

Mais bon comme tu dis Agylus, on entre sur des questions infinies et impossibles à résoudre tant les avis sont équitablement partagés.

a écrit :
Quant à l'imperfection sémantique de HTML, ce n'est vraiment pas sur ce genre de choses qu'elle se manifeste.

Entre autres, m'enfin quand même, si ce débat de l'utilisation de <p> perdure depuis aussi longtemps, c'est qu'à mon humble avis, il y a des lacunes à combler sur le plan sémantique de ce côté là. Dont le sujet actuel.
On ne devrait même pas avoir à se poser la question, ni à interpréter de 36 manières possibles les spécifications du w3c
Modifié par Nigel (06 Jul 2009 - 16:00)

Une chose semble plus clair pour moi maintenant, rien n'empêche d'utiliser des <div> pour lister les élément d'un formulaire, tout autant qu'un <p>.

Chacun pourra à loisir et en fonction de ses affinités avec tel ou tel élément les eux solutions au final semble se valoir.

merci à vous...

Oui, je pense qu'aucun d'entre nous ici ne criera au loup quand il remarquera l'usage d'un <p> ou d'un <div> pour cela. Même si nous sommes parfois des fervents défenseurs de l'une ou l'autre solution. ^^

On ne va tout même pas être extrémistes à ce point quand même... Ce sont des questions totalement pointilleuses et/ou débatables indéfiniement qui sont posées ici.
Modifié par Nigel (06 Jul 2009 - 16:04)

Nigel a écrit :
De plus, n'oublions pas le "fieldset"...

Qui sert à associer un LEGEND aux LABEL (ou title) des champs de formulaire.

Nigel a écrit :
Entre autres, m'enfin quand même, si ce débat de l'utilisation de <p> perdure depuis aussi longtemps, c'est qu'à mon humble avis, il y a des lacunes à combler sur le plan sémantique de ce côté là.

Non, c'est que certains se sont fixés pour but de trouver une sémantique pour chaque contenu ou micro-contenu d'une page, et un balisage plus-super-top-pertinent pour y correspondre. Et qu'il y a une tendance à «mettre de la sémantique» dans les documents HTML sans trop savoir ce que ça veut dire.

Pour reprendre sur la sémantique HTML:

1. La spécification dit «les éléments ont une sémantique, il est convenable de la respecter et de ne pas utiliser un élément à la place d'un autre» (grosso modo ce qui est dit dans HTML 5, je ne sais plus si c'est aussi explicite dans HTML 4).

Cette injonction ne doit pas être prise trop strictement pour les raisons suivantes:

2. La sémantique HTML est «pauvre» dans la mesure où le nombre d'éléments disponibles est réduit et ne transcrit pas les modalités de discours, n'identifie pas les auteurs et locuteurs, propose très peu de chose (du moins dans HTML 4) pour des interfaces applicatives, etc. En conséquence, un certain nombre d'éléments ont un rôle très générique. Il y a bien sûr les deux conteneurs génériques dépourvus de toute sémantique (en l'absence d'attributs sémantiques tels que lang), à savoir DIV et SPAN. Mais aussi quelques autres conteneurs parmi lesquels P, UL/OL/DL (tel que définis dans HTML 4). Il arrive qu'utiliser un de ces éléments semi-générique de telle ou telle manière soit un abus; cet abus peut dans certains cas être déduit de la spécification (utilisation de DT/DD en substitution d'un titrage), et dans d'autres cas relève surtout de questions d'accessibilité et du mode de restitution choisi par les aides techniques (un LI pourrait être considéré comme un conteneur semi-générique plutôt que comme une étape d'une énumération s'il n'était pas annoncé par les aides techniques, rendant les structures en listes imbriquées assez imbitables).

3. La sémantique HTML n'a aucun intérêt si elle n'a pas d'usage concret, ou si on ne peut pas raisonnablement supposer une utilisation concrète future. Pour un problème donné, il est donc utile de se référer non seulement au texte (souvent très vague dans le cas de HTML 4) mais aussi aux implémentations concrètes des agents utilisateurs (navigateurs, aides techniques, outils d'indexation...). À ce sujet, je ne peux que conseiller de travailler les questions d'accessibilité; cela permet de se concentrer sur ce qui compte, et de ne pas se focaliser uniquement sur ce qui ne sert à rien.

Nigel a écrit :
On ne devrait même pas avoir à se poser la question, ni à interpréter de 36 manières possibles les spécifications du w3c

HTML 4 a été rédigé rapidement, avec peu de recul, est peu détaillé et a de très nombreuses lacunes techniques. Donc si, ça demande des interprétations. Il n'y en a heureusement jamais 36 pour un problème donné.

On notera au passage qu'une partie du travail sur HTML 5 est une réinterprétation de HTML 4. On peut être en désaccord sur certains points, bien sûr.
Modifié par Florent V. (06 Jul 2009 - 16:59)

Je pense m'être totalement mal exprimé dans le sens où je suis entièrement d'accord avec tes contre-arguments.

Non mais, il y a juste une chose qui me dérange, c'est la simple question du pourquoi "p" alors qu'on a "div" qui correspond tout à fait, qui existe pour la raison même de cette question, qui ne pose aucune question subsidiaire.
Alors que l'utilisation de "p" vient poser là une tonne de questions "fondamentales" sur les standards du web, sur la sémantique, sur le sens premier du terme paragraphe, sur... bref.
L'utilisation du "p" dans ce contexte précis me semble bien trop ambigü et douteux sur certains points.

Si nous n'avions pas le choix, je ne dirais tout simplement rien. Mais en l'occurence...

Et comme je le disais plus haut, certains choisissent d'utiliser <p> PARCE QUE les navigateurs ajoutent une marge par défaut... Et que donc, si on désactive les feuilles de styles, et bien ca fait plus beau. Non non et non, c'est là que je m'insurge particulièrement et cela remet en cause les fondements même des recommandations. Même si ce n'est pour autant pas si grâvissime, dans le cas présent. Mais il s'agit là d'une question tout de même fondamentale.

Enfin ceci dit, les choses vont évoluer avec l'(x)HTML5, et tant mieux oui, mais d'ici là, on ne va pas non plus s'amuser à réinventer la roue, sous justification que les recommandations sont floues.
Et c'est là que je rejoins ce post.

---
PS :

a écrit :
Qui sert à associer un LEGEND aux LABEL (ou title) des champs de formulaire.

Bien entendu, je parlais juste de la présence éventuelle d'un fieldset qui rajoute, à l'instar d'un <p>, une marge. Mais il faut remettre la phrase dans son contexte, je pense.
D'un autre côté, un fieldset a son utilité spécifique, comme l'a le "paragraphe"...
Mais bon là on continue de tourner en rond.
Modifié par Nigel (06 Jul 2009 - 17:48)

Arsene,

a écrit :
il y a justement des textes dans le formulaire [...] la question se résoud toute seule

Le problème est qu'il y a aussi autre chose que du texte, et c'est ça qui, selon moi, est bloquant. Le fait qu'un tableau contienne du texte n'en fait pas un paragraphe pour autant.

Florent,

Le principe qu'une position à valeur normative définisse la sémantique d'un élément :
1) en se basant sur le "mode de restitution" et les "implémentations" actuelles par les UA (et pas seulement dans le cas d'HTML)
2) en tentant de standardiser bon nombre de pratiques non standard des développeurs des dernières années (cf. "pave the cowpath" ; je fais partie de ceux qui pensent que la "dilatation" du paragraphe en HTML 5 en est une manifestation)
... me laisse pour le moins perplexe . Je sais qu'il doit y avoir des bonnes raisons (aucune ironie) mais je n'arrive pas à en trouver tout seul, et je pense que des discussions comme celles-ci sont un excellent endroit pour les apprendre.

Florent, je comprends ton pragmatisme et le partage naturellement sur le fond. Le paragraphe va bientôt servir officiellement de pseudo-mini-div et, content, pas content, je l'utiliserai et le recommanderai. Cependant, l'on opine bien sur les lois que nous pond le gouvernement, qu'on nous laisse donc opiner sur les normes que nous prépare le W3C, sans être taxés de maniaques de "ce qui ne sert à rien" .

PS: l'article de Tommy Olsson a deux ans mais sa position n'a pas changé (cf. Sitepoint, Google, ...)

@marcv Quoi d'autre qui ne serait pas défini par une balise et/ou qui ne soit pas un tag d'objets de formulaire ?
Dans une table il y a une notion de lien organique entre cellules et colonnes, d'où l'intérêt de la balise table, mais dans un form je ne vois pas ? Il y a des objets de formulaire + des textes aidant à l'usage du form.

Eh bien, comme je l'ai dit depuis le début, des divs font très bien l'affaire, puisque je ne vois pas ce que l'on a à gagner sémantiquement (c'est de ça dont on parle) en utilisant un <p>.
Mais maintenant que j'y pense et que tu me le rappelles, un tableau m'apparaît comme une très bonne solution, justement pour ce lien organique que tu évoques entre les colonnes. Un truc dans ce style, par exemple me semble personnellement très acceptable :

<table>
    <tr>
        <td>label</td>
        <td>input</td>
    </tr>
    <tr>
        <td>label</td>
        <td>boutons radio</td>
    </tr>
    <tr>
        <td>label</td>
        <td>textarea</td>
    </tr>
</table>

Nombre de formulaires, dans la "vraie vie", par exemple, ne sont rien d'autre que de bêtes tableaux. Je pense à la déclaration de revenus, par exemple...

Edit : et probablement des th pour les label, bon enfin, c'est l'idée, quoi...
Modifié par marcv (06 Jul 2009 - 19:42)

La petite information qui va bien: en réalité, je ne souscris pas au principe de séparation de la mise en forme et du contenu.

Donc utiliser P pour obtenir des écarts facilitant la lecture avec un affichage par défaut, ça me va très bien et ça ne me choque nullement (vu que par ailleurs je n'estime pas que P est réservé à des paragraphes au sens littéraire).

marcv a écrit :
Eh bien, comme je l'ai dit depuis le début, des divs font très bien l'affaire, puisque je ne vois pas ce que l'on a à gagner sémantiquement (c'est de ça dont on parle) en utilisant un <p>.

Ça fait juste 3-4 messages que je dis qu'il ne s'agit pas de sémantique (pour l'usage que j'en fais), mais qu'il s'agit plutôt:

1. de méthodologie (c'est une convention de codage facilitant les choix de balisage);
2. d'une astuce pratique pour obtenir un rendu sans CSS satisfaisant.

Étant donné que a) la théorie de la sémantique HTML (HTML 4 muet ou implicite, HTML 5 explicite) ne contredit pas cet usage, et que b) la réalité de la sémantique HTML (UA, aides techniques) ne contredit pas cet usage, eh bien tout va bien.

Qu'est-ce qu'on a à gagner sémantiquement? Rien. Est-ce qu'on s'en fout: heureusement, oui.

marcv a écrit :
Mais maintenant que j'y pense et que tu me le rappelles, un tableau m'apparaît comme une très bonne solution, justement pour ce lien organique que tu évoques entre les colonnes.

Allons bon, voilà maintenant qu'on voudrait doubler un système qui marche et qui est précis (<label for="..."></label>) par une surcouche à coup de colonnes de tableau. Fort heureusement, ce tableau n'est pas sémantique (pour un lecteur d'écran) et sera interprété comme un tableau de mise en page, donc pas très différemment (voire pas du tout) d'une série de DIV ou P. Ouf. Avec un tableau sémantique (avec des <th scope="col"> par exemple), on aurait eu une légère surcharge d'information tout de même.