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

(reprise du message précédent)

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.

marcv a écrit :
Décidément très HTML5, Florent

Je suis même pire que HTML 5. Je trouve les tableaux de mise en page très propre sur eux, tandis qu'HTML 5 les déconseille vivement. Comme quoi, tous les chemins de chèvres ne sont pas pavés.

J'ai quelques autres critiques sur HTML 5, notamment des doutes sérieux sur l'intérêt pratique (et la capacité des auteurs à exploiter correctement) SECTION, HEADING, et les plans de documents morcelés (H3 introduisant une SECTION contenant un H1 puis un HEADING avec H2 et H3, puis un H2, fin de section, retour à un H3 ou descente sur un H4 ou remontée sur un H1 ou H2...). Le status quo sur OBJECT/EMBED n'est pas terrible (mais je suis peu informé sur le sujet). J'aime bien la redéfinition partielle de B et I, par contre.

Mais globalement, oui, je suis plutôt convaincu (et j'étais plutôt anti-XHTML 2).

Moi qui suis plutôt "séparation des contenus avec la mise en page" à l'extrême... (pour moi, le site parfait est en xml+xslt pour en générer du (x)html pour un navigateur, du rss pour un lecteur de flux, de l'information brute pour une interface riche etc.)

Je me doute bien que je suis sûrement bien plus à coté de la plaque que toi Florent sur ce coup là. Néanmoins, j'aimerais bien que tu m'expliques l'intérêt que tu vois dans ta solution.

As tu déjà eu des problèmes de portabilité du contenu à cause d'une interface peu flexible ? (Pour l'impression, les smartphones, etc.) Je me doute que non, mais pour le coup : comment fais-tu ? Tu redéveloppes pour chaque support ?

Pour le problème en cours, je me pose une question quand même : pourquoi vouloir englober le label + input dans un parent ? Pour de la facilité de manipulation ?
Modifié par Niaa (09 Jul 2009 - 15:29)

Niaa a écrit :
As tu déjà eu des problèmes de portabilité du contenu à cause d'une interface peu flexible ? (Pour l'impression, les smartphones, etc.) Je me doute que non, mais pour le coup : comment fais-tu ? Tu redéveloppes pour chaque support ?

Déjà, je n'ai pas travaillé (en dehors de quelques essais perso) sur des sites destinés aux smartphones (même partiellement). Pour la gestion screen/print, ça se gère bien en CSS avec un code HTML plutôt destiné (en ce qui concerne les conteneurs supports de styles) à l'affichage pour l'écran. Pour des usages plus avancés d'édition de documents (vers format PDF par exemple), des outils ad hoc tels que Prince XML sont plus adaptés, et on souhaitera sans doute faire des templates XML dédiés à ces usages particuliers.

Globalement, quand on a des besoins assez précis et divergents en termes de restitution, on aura intérêt à traiter ça en amont, côté serveur, plutôt que côté client. Que ça se fasse via des jeux de templates depuis une base de données, ou en XSLT côté serveur, peu importe.

Niaa a écrit :
Pour le problème en cours, je me pose une question quand même : pourquoi vouloir englober le label + input dans un parent ? Pour de la facilité de manipulation ?

Parce qu'en général, en termes de logique comme pour un affichage minimal: ceci est peu compréhensible:

Label 1 Input 1 Label 2 Input 2 Label 3 Input 3 Label 4 Input 4 Label 5 Input 5 Label 6 Input 6 Label 7 Input 7 Label 8 Input 8

tandis que ceci sera tout de même plus logique:

Label 1 Input 1
Label 2 Input 2
Label 3 Input 3
Label 4 Input 4
Label 5 Input 5
Label 6 Input 6
Label 7 Input 7
Label 8 Input 8

Et, bien sûr, les besoins de mise en page vont imposer la présence d'un balisage regroupant les groupes logiques. À minima, ça sera pour les retours à la ligne. Suivant les besoins, ça peut être pour gérer des espacement verticaux, des filets entre les groupes, des mises en page différentes activées par un jeu de classes, etc.

J'ai dû mal te comprendre, mais ta question revient un peu à demander: «pourquoi utiliser des conteneurs, plutôt que de tout mettre en vrac?»

Bien entendu, pour un formulaire de recherche avec champ texte et bouton de validation accolés, pas besoin de DIV ou P ou autre conteneur que le FORM (sauf besoin de mise en page ou de validation en HTML 4 Strict...).