Devrais-je mettre des éléments d'entrée dans un élément label?
Existe-t-il une meilleure pratique concernant l'imbrication d'éléments label et input HTML?
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>
From w3: Le libellé lui-même peut être placé 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'une table est utilisée pour la présentation, avec l'étiquette dans une cellule et le 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 à styler 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>
Code semble encore mieux à mon avis.
Si vous incluez la balise input dans la balise label, vous n'avez pas besoin d'utiliser l'attribut 'for'.
Cela dit, je n'aime pas inclure la balise input dans mes étiquettes, car je pense qu'elles sont séparées et non contenir des 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, celle-ci n'est activée que si l'étiquette contient l'entrée.
Cela a du sens puisque dans ce cas l’espace n’est qu’un autre caractère de l’étiquette.
<p>Inside:</p>
<label>
<input type="checkbox" />
|<----- Label. Click between me and the checkbox.
</label>
<p>Outside:</p>
<input type="checkbox" id="check" />
<label for="check">|<----- Label. Click between me and the checkbox.</label>Pouvoir cliquer entre étiquette et case signifie que c'est:
- plus facile à cliquer
- moins clair où les choses commencent et finissent
Les exemples de case à cocher Bootstrap v3.3 utilisent les entrées suivantes: http://getbootstrap.com/css/#forms Il serait sage 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:
L'utilisation des cases à cocher et des radios est conçue pour prendre en charge la validation de formulaire basée sur HTML et fournir des libellés concis 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 les attributs doivent associer les<input>et<label>.
Question UX traitant de ce point en détail: https://ux.stackexchange.com/questions/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 ait l'air agréable (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" />
Cela me permet d’é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 de manière explicite (en utilisant "pour" avec l'identifiant de l'élément) et implicite (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 identique à la valeur de l'attribut id de l'élément de contrôle associé.
Implicite:
Pour associer implicitement une étiquette à un autre contrôle, l'élément de contrôle doit être contenu dans le contenu de l'élément LABEL. Dans ce cas, le LABEL ne peut contenir qu'un seul élément de contrôle.
Les deux sont corrects, mais l'insertion dans l'étiquette le rend beaucoup moins flexible lors du style avec CSS.
Tout d'abord, n <label> _ est restreint quant aux éléments qu'il peut contenir . Par exemple, vous pouvez uniquement insérer un <div> entre le <input> et le texte de l'étiquette, si le <input> ne se trouve pas dans le <label>.
Deuxièmement, bien qu'il existe des solutions de contournement pour faciliter le style, comme l'enveloppe du texte de l'étiquette interne, certains styles sont hérités des éléments parents, ce qui peut compliquer davantage le style.
Un 'gotcha' notable indique que vous ne devez jamais inclure plus d'un élément d'entrée dans un élément <label> avec un attribut explicite "pour", 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 par le clic de l'élément label mettra immédiatement en évidence l'élément dont l'identifiant est explicitement défini dans l'attribut 'for' , il est presque impossible pour l'utilisateur de cliquer dans le champ de texte contenu pour saisir 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.
Je vais généralement avec les deux premières options. J'ai vu un scénario où la troisième option était utilisée, lorsque les choix de radio étaient intégrés aux étiquettes et aux fichiers CSS, ce qui
label input {
vertical-align: bottom;
}
afin d’assurer un alignement vertical correct des radios.
Comme la plupart des gens l'ont dit, les deux méthodes fonctionnent, mais je pense que seul le premier devrait suffire. 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 du 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. Donc l'option numéro deux est arbitraire et déroutante. Tous ceux qui ont lu le Zen de Python seront probablement d’accord (Flat vaut mieux que niché, Sparse vaut mieux que dense, Il devrait y avoir un - et de préférence un seul moyen - évident de le faire .. .).
En raison de décisions de ce type prises par le W3C et les principaux éditeurs de navigateurs (autorisant "quelle que soit la méthode choisie, au lieu de" le faire de la bonne façon "), le Web est tellement perturbé aujourd'hui et nous, les développeurs, devons gérer des problèmes complexes. et code hérité si divers.
En référence à la WHATWG ( Écriture de l'interface utilisateur d'un formulaire ), il n'est pas mauvais de placer le champ de saisie à l'intérieur de l'étiquette. . Cela vous permet d'économiser du code car l'attribut for de label n'est plus nécessaire.
Je préfère grandement envelopper des éléments dans mon <label> parce que 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-même ou par d'autres. Il serait alors facile de dupliquer un identifiant dans la page, conduisant là à des comportements étranges.