Dois-je mettre des éléments d'entrée dans un élément d'étiquette?

Existe-t-il une meilleure pratique concernant l'imbrication des éléments HTML labelet input?

manière classique:

<label for="myinput">My Text</label>
<input type="text" id="myinput" />

ou

<label for="myinput">My Text
   <input type="text" id="myinput" />
</label>

À partir de w3: l'étiquette elle-même peut être positionnée avant, après ou autour du contrôle associé.

<label for="lastname">Last Name</label>
<input type="text" id="lastname" />

ou

<input type="text" id="lastname" />
<label for="lastname">Last Name</label>

ou

<label>
   <input type="text" name="lastname" />
   Last Name
</label>

Notez que la troisième technique ne peut pas être utilisée lorsqu'un tableau est utilisé pour la mise en page, avec l'étiquette dans une cellule et son champ de formulaire associé dans une autre cellule.

L'un ou l'autre est valide. J'aime utiliser le premier ou le deuxième exemple, car cela vous donne plus de contrôle sur le style.

je préfère

<label>
  Firstname
  <input name="firstname" />
</label>

<label>
  Lastname
  <input name="lastname" />
</label>

plus de

<label for="firstname">Firstname</label>
<input name="firstname" id="firstname" />

<label for="lastname">Lastname</label>
<input name="lastname" id="lastname" />

Principalement parce que cela rend le HTML plus lisible. Et je pense en fait que mon premier exemple est plus facile à styliser avec CSS, car CSS fonctionne très bien avec les éléments imbriqués.

Mais c'est une question de goût je suppose.

Si vous avez besoin de plus d'options de style, ajoutez une balise span.

<label>
  <span>Firstname</span>
  <input name="firstname" />
</label>

<label>
  <span>Lastname</span>
  <input name="lastname" />
</label>

Le code semble toujours meilleur à mon avis.

Si vous incluez la balise d'entrée dans la balise label, vous n'avez pas besoin d'utiliser l'attribut 'for'.

Cela dit, je n'aime pas inclure la balise d'entrée dans mes étiquettes car je pense que ce sont des entités séparées, ne contenant pas d'entités.

Différence de comportement: cliquer dans l'espace entre l'étiquette et l'entrée

Si vous cliquez sur l'espace entre l'étiquette et l'entrée, elle active l'entrée uniquement si l'étiquette contient l'entrée.

Cela est logique car dans ce cas, l'espace n'est qu'un autre caractère de l'étiquette.

<p>Inside:</p>

<label>
  <input type="checkbox" />
  |&lt;----- Label. Click between me and the checkbox.
</label>

<p>Outside:</p>

<input type="checkbox" id="check" />
<label for="check">|&lt;----- Label. Click between me and the checkbox.</label>

Pouvoir cliquer entre l'étiquette et la boîte signifie que c'est:

• plus facile à cliquer
• moins clair où les choses commencent et se terminent

Les exemples de la case à cocher Bootstrap v3.3 utilisent l'entrée à l'intérieur: http://getbootstrap.com/css/#forms Il pourrait être judicieux de les suivre. Mais ils ont changé d'avis dans la v4.0 https://getbootstrap.com/docs/4.0/components/forms/#checkboxes-and-radios donc je ne sais plus ce qui est sage:

Les cases à cocher et les radios sont conçues pour prendre en charge la validation de formulaire HTML et fournir des étiquettes concises et accessibles. En tant que tels, nos <input>s et <label>s sont des éléments frères par opposition à un <input>dans un <label>. Ceci est légèrement plus détaillé car vous devez spécifier id et pour que les attributs relient le <input>et <label>.

Question UX qui traite de ce point en détail: /ux/23552/should-the-space-between-the-checkbox-and-label-be-clickable

Personnellement, j'aime garder l'étiquette à l'extérieur, comme dans votre deuxième exemple. C'est pourquoi l'attribut FOR est là. La raison étant que je vais souvent appliquer des styles à l'étiquette, comme une largeur, pour que le formulaire soit joli (raccourci ci-dessous):

<style>
label {
  width: 120px;
  margin-right: 10px;
}
</style>

<label for="myinput">My Text</label>
<input type="text" id="myinput" /><br />
<label for="myinput2">My Text2</label>
<input type="text" id="myinput2" />

Fait en sorte que je puisse éviter les tableaux et toutes ces ordures dans mes formulaires.

Voir http://www.w3.org/TR/html401/interact/forms.html#h-17.9 pour les recommandations W3.

Ils disent que cela peut être fait de toute façon. Ils décrivent les deux méthodes comme explicites (en utilisant "pour" avec l'identifiant de l'élément) et implicites (en incorporant l'élément dans l'étiquette):

Explicite:

L'attribut for associe explicitement une étiquette à un autre contrôle: la valeur de l'attribut for doit être la même que la valeur de l'attribut id de l'élément de contrôle associé.

Implicite:

Pour associer une étiquette à un autre contrôle implicitement, l'élément de contrôle doit se trouver dans le contenu de l'élément LABEL. Dans ce cas, LABEL ne peut contenir qu'un seul élément de contrôle.

Les deux sont corrects, mais mettre l'entrée à l'intérieur de l'étiquette le rend beaucoup moins flexible lors du style avec CSS.

Tout d'abord, a <label>est limité dans les éléments qu'il peut contenir . Par exemple, vous ne pouvez mettre un <div>entre le <input>et le texte de l'étiquette que si le <input>n'est pas à l'intérieur du <label>.

Deuxièmement, bien qu'il existe des solutions de contournement pour rendre le style plus facile, comme habiller le texte de l'étiquette intérieure avec une étendue, certains styles seront hérités des éléments parents, ce qui peut rendre le style plus compliqué.

Un "gotcha" notable dicte que vous ne devez jamais inclure plus d'un élément d'entrée à l'intérieur d'un élément <label> avec un attribut "for" explicite, par exemple:

<label for="child-input-1">
  <input type="radio" id="child-input-1"/>
  <span> Associate the following text with the selected radio button: </span>
  <input type="text" id="child-input-2"/>
</label>

Bien que cela puisse être tentant pour les fonctionnalités de formulaire dans lesquelles une valeur de texte personnalisée est secondaire à un bouton radio ou à une case à cocher, la fonctionnalité de mise au point du clic de l'élément d'étiquette jettera immédiatement le focus à l'élément dont l'ID est explicitement défini dans son attribut `` pour '' , ce qui rend presque impossible pour l'utilisateur de cliquer dans le champ de texte contenu pour entrer une valeur.

Personnellement, j'essaie d'éviter les éléments d'étiquette avec des enfants d'entrée. Il semble sémantiquement inapproprié qu'un élément d'étiquette englobe plus que l'étiquette elle-même. Si vous imbriquez des entrées dans des étiquettes afin d'obtenir une certaine esthétique, vous devriez plutôt utiliser CSS.

Comme la plupart des gens l'ont dit, les deux méthodes fonctionnent effectivement, mais je pense que seule la première devrait l'être. Étant sémantiquement strict, l'étiquette ne "contient" pas l'entrée. À mon avis, la relation de confinement (parent / enfant) dans la structure de balisage devrait refléter le confinement dans la sortie visuelle . c'est-à-dire qu'un élément entourant un autre dans le balisage doit être tracé autour de celui-ci dans le navigateur . Selon cela, l'étiquette devrait être le frère de l'entrée, pas son parent. L'option numéro deux est donc arbitraire et déroutante. Tous ceux qui ont lu le Zen de Python seront probablement d'accord (Flat est meilleur que imbriqué, Sparse vaut mieux que dense, Il devrait y en avoir une - et de préférence une seule - une façon évidente de le faire ...).

En raison de décisions telles que celles du W3C et des principaux fournisseurs de navigateurs (autorisant "la façon dont vous préférez le faire", au lieu de "le faire de la bonne manière"), le Web est tellement foiré aujourd'hui et nous, les développeurs, devons faire face à des problèmes et un code hérité si diversifié.

Je choisis généralement les deux premières options. J'ai vu un scénario lorsque la troisième option a été utilisée, lorsque les choix radio étaient intégrés dans les étiquettes et le CSS contenait quelque chose comme

label input {
    vertical-align: bottom;
}

afin d'assurer un bon alignement vertical des radios.

En se référant au WHATWG ( Écriture de l'interface utilisateur d'un formulaire ), il n'est pas faux de mettre le champ de saisie à l'intérieur de l'étiquette. Cela vous permet d'économiser du code car l' forattribut de labeln'est plus nécessaire.

Je préfère grandement envelopper les éléments dans mon <label>car je n'ai pas à générer les identifiants.

Je suis un développeur Javascript et React ou Angular sont utilisés pour générer des composants qui peuvent être réutilisés par moi ou par d'autres. Il serait alors facile de dupliquer un identifiant dans la page, ce qui entraînerait des comportements étranges.

Une chose que vous devez considérer est l'interaction des cases à cocher et des entrées radio avec javascript.

En utilisant la structure ci-dessous:

<label>
  <input onclick="controlCheckbox()" type="checkbox" checked="checkboxState" />
  <span>Label text</span>
</label>

Lorsque l'utilisateur clique sur "Texte du libellé", la fonction controlCheckbox () est déclenchée une fois.

Mais lorsque la balise d'entrée est cliquée, la fonction controlCheckbox () peut être déclenchée deux fois dans certains navigateurs plus anciens. En effet, les balises d'entrée et d'étiquette déclenchent un événement onclick attaché à la case à cocher.

Ensuite, vous pouvez avoir des bogues dans votre checkboxState.

J'ai rencontré ce problème récemment sur IE11. Je ne sais pas si les navigateurs modernes ont des problèmes avec cette structure.

Le principal avantage de placer à l' inputintérieur delabel est l'efficacité de la frappe pour les humains et le stockage des octets pour les ordinateurs.

@Znarkus a déclaré dans son commentaire au PO,

L'un des grands avantages de mettre l' <input />intérieur <label>, c'est que vous pouvez omettre foret id: <label>My text <input /></label>dans votre exemple. Tant mieux!

Remarque: Dans le code @Znarknus, une autre efficacité a été incluse non explicitement indiquée dans le commentaire. type="text"peut également être omis et inputaffichera une zone de texte par défaut.

Une comparaison côte à côte des frappes et des octets [1].

31 frappes, 31 octets

<label>My Text<input /></label>

58 touches, 58 octets

<label for="myinput">My Text</label><input id="myinput" />

Sinon, les extraits sont visuellement égaux et offrent le même niveau d'accessibilité aux utilisateurs. Un utilisateur peut cliquer ou toucher l'étiquette pour placer le curseur dans la zone de texte.

[1] Fichiers texte (.txt) créés dans le Bloc-notes sous Windows, octets des propriétés de l'Explorateur de fichiers Windows