Utilisation du tag label en dehors d'un formulaire

Bonjour à tous.

Je suis en train de refaire mon site web et je m'interroge sur l'utilisation que je fais du tag label.

Lorsque j'ai besoin de saisir des données, je passe par des champs de formulaire que je représente de la façon suivante :

<p>
<label for="monchamp">Mon champ</label>
<input type="text" id="monchamp" name="monchamp">
</p>

Jusque là, je n'ai pas de problème. C'est pour la consultation des données que je me pose des questions. Actuellement, j'utilise la représentation suivante :

<p>
<label>Mon champ</label>
La valeur enregistrée pour ce champ
</p>

Au niveau présentation, ça s'affiche correctement. Au niveau de la validation, c'est considéré comme juste. Mais j'ai un doute sur la validité de cette manière de faire.

-Est-il correct d'utiliser le tag label en dehors d'un formulaire ?
-Comment représentez vous les données issues d'un formulaire lors de
la génération d'une page de consultation ?

Merci d'avance pour vos remarques.

Bonsoir,

Pour ma part je ne vois aucun intérêt à l'utilisation de la balise label en dehors d'un formulaire.

Comme d'habitude c'est un avis personnel... S'il y a un intérêt je serais heureux de le connaitre

++

Salut,

Ce n'est nullement un problème de présentation. Les balises ont un sens (sémantique). Donc <label> à un sens. Si tu détournes ce sens au profit d'une solution de présentation, les utilisateurs qui se servent de la sémantique pour leurs dispositifs particuliers vont être perdus.

Pour ton problème, la sémantique te propose les listes de définition, parfaitement adaptées à ce que tu veux coder.

Bon courage

Je n'utilisais pas la balise <label> dans un souci ce présentation. C'était justement pour donner du sens à mon code html. La balise <label> permettant de définir le libellé d'un champ, ça me semblait une bonne idée. Mais ne le voyant jamais utilisé en dehors d'un formulaire, j'ai commencé à douter.

N'ayant jamais utilisé les listes de définitions, j'avais complètement oublié cette possibilité.
Je vais creuser un peu l'usage de ces balises.

Merci.

J'ai creusé un peu la question des listes de définition.
Et j'hésite sur la validité sémantique de leur usage pour mon besoin.

Là ou la liste de définition associe un mot et sa définition, je réalise une association de la forme libellé d'un champ / valeur.

C'est pour cela que l'usage de la balise label me semblait pertinente.
Son usage en dehors d'un formulaire, beaucoup moins et surtout, si j'isolais bien le libellé, la valeur du champ, elle, était perdue dans mon paragraphe.

La liste de définition, ele, me permet d'isoler le libellé de l'information qui lui est rattaché.

Peut-être que je me prends la tête pour rien et que j'ai une vision trop "étroite" de la définition des listes de valeur.

Je n'aurai pas ces problèmes si j'utilisais des tableaux comme au bon vieux temps

Cyril P. a écrit :
Là ou la liste de définition associe un mot et sa définition, je réalise une association de la forme libellé d'un champ / valeur.

Association logique champ/valeur sans marquage sémantique: mettre les deux textes l'un à la suite de l'autre. Exemple de code:

<p>
	<span class="champ">Champ:</span>
	<span class="valeur">valeur.</span>
</p>
<!-- les span sont ajoutés au cas où on voudrait jouer sur la mise en forme -->

Association logique champ/valeur avec marquage sémantique: faire un tableau à deux colonnes, structuré avec des en-têtes pour chaque colonne (éléments th avec attribut scope).

Si on se contente de faire un tableau juste pour la mise en forme induite, sans utiliser d'en-tête pour les colonnes ou autre marquage sémantique propre aux tableaux de données, on obtient une solution tout à fait équivalente à celle dont je donne le code plus haut.

Pour la liste de définitions, l'utiliser dans ce genre de cas correspond soit à une extrapolation de la portée sémantique des listes de définitions, soit à un usage abusif (suivant les points de vue). Pour ma part, j'évite de les utiliser en dehors des listes de définitions, glossaires, etc.

Pourquoi pas à ce moment-là mettre des <input readonly="readonly" /> ?
Là tes labels serviront à quelque chose. En plus ça ajoute une fonction qui pourrait être utile suivant les cas, celle de pouvoir copier-coller plus facilement...
Rien ne t'empêche de mettre du CSS derrière pour que tes input ressemblent à tout sauf à des champs de formulaires ordinaires.

Florent V., je croyais qu'utiliser les tableaux pour faire de la mise en page, c'était le mal

Je pense que je vais utiliser la solution à base de <span> que j'avais déjà en tête mais sans l'avoir appliqué. La liste de définition semble effectivement faire débat sur l'extension de son périmètre d'utilisation.

QuentinC, est ce que ce n'est pas un peu "too much" de générer un formulaire qui ne servira qu'à traiter des données ? Ca fait un peu faire rentrer un rond dans un carré, non ?

Merci et bonne soirée.

Cyril P. a écrit :
Là ou la liste de définition associe un mot et sa définition, je réalise une association de la forme libellé d'un champ / valeur.

C'est pour cela que l'usage de la balise label me semblait pertinente.

Non. Un label n'est pas un libellé au sens où il serait un terme générique que le champ (ou plutôt son contenu) viendrait expliciter, ou au sens où il créerait un couple champ/valeur. C'est au contraire le label qui qualifie et explique le rôle du champ, dont le contenu est indifférent. Un label, ça dit juste le champ machin va vous permettre de saisir cela.... C'est bête, mais du coup très efficace, un label

En d'autres termes, label-input et dt-dd sont des relations exactement inverses (ce qui fait que la structure de formulaire à base de liste de définition encore à la mode il y a peu était une sottise, mais passons sur les choses qui faisaient si mal mais qui vont disparaître une fois l'effet de mode passé)

Cyril P. a écrit :

Son usage en dehors d'un formulaire, beaucoup moins

Oui, de toutes façons, ce sont surtout des considérations très douloureuses pour les dioptères, étant donné qu'un label n'a aucun sens fonctionnel s'il n'est pas associé explicitement (FOR, ID) à un contrôle (input, select etc.) Autrement dit, aucune "Sémantique" en dehors de son usage dans un formulaire, tout comme les fieldset.

Cyril P. a écrit :

et surtout, si j'isolais bien le libellé, la valeur du champ, elle, était perdue dans mon paragraphe.

Oui. ce que tu tentais de faire avec le label, c'est ce que fait DFN. avec le même problème de valeur du champ suspendue en l'air, quelque-part dans l'élément parent, mais sans qu'on sache exactement la délimiter.

Cyril P. a écrit :

La liste de définition, ele, me permet d'isoler le libellé de l'information qui lui est rattaché.

Peut-être que je me prends la tête pour rien et que j'ai une vision trop "étroite" de la définition des listes de valeur.

La politique en la matière (les dl) risque de devenir très rigoriste et limitative, après le RGAA qui limite strictement leur usage au couple "terme/définition" pour des raisons pragmatiques (si vous voulez râler à ce sujet, allez-y, je plaide coupable pour le coup des dl ). L'usage ouvert par HTML était plus large (d'où son état complètement inutilisable).

Cyril P. a écrit :

Je n'aurai pas ces problèmes si j'utilisais des tableaux comme au bon vieux temps

Un tableau de données ? Mais, en voilà une excellente idée, simple, rapide, accessible, sémantique, tout ça... (sachant que tes libellés de champs seront des en-têtes de ligne dans des tableaux à simple entrée comme Florent l'a très bien expliqué)...

<edit>Nous sommes souvent tentés de forcer ce pauvre HTML pour qu'il nous permette de faire cette chose qui le dépasse mais qui semble pourtant toute simple: une paire de contenus avec une relation univoque. Mais HTML est foncièrement plat. La seule chose qui associe vaguement une chose à une autre est la plupart du temps tout simplement l'ordre dans lequel deux contenus se présentent dans le code: comme les titres qui ne font que précéder les contenus concernés.</>
Modifié par Laurent Denis (19 Nov 2007 - 19:21)