Devo inserire elementi di input all'interno di un elemento etichetta?

C'è una best practice relativa alla nidificazione di labele inputelementi HTML?

modo classico:

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

o

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

Da w3: l'etichetta stessa può essere posizionata prima, dopo o attorno al controllo associato.

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

o

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

o

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

Si noti che la terza tecnica non può essere utilizzata quando una tabella viene utilizzata per il layout, con l'etichetta in una cella e il campo del modulo associato in un'altra cella.

Uno dei due è valido. Mi piace usare il primo o il secondo esempio, poiché ti dà un maggiore controllo dello stile.

preferisco

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

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

al di sopra di

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

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

Principalmente perché rende l'HTML più leggibile. E in realtà penso che il mio primo esempio sia più semplice da modellare con i CSS, poiché i CSS funzionano molto bene con elementi nidificati.

Ma suppongo sia una questione di gusti.

Se hai bisogno di più opzioni di stile, aggiungi un tag span.

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

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

Secondo me, il codice sembra ancora migliore.

Se includi il tag di input nel tag label, non è necessario utilizzare l'attributo 'for'.

Detto questo, non mi piace includere il tag di input nelle mie etichette perché penso che siano entità separate, non contenenti.

Differenza di comportamento: fare clic nello spazio tra etichetta e input

Se si fa clic sullo spazio tra l'etichetta e l'input, si attiva l'input solo se l'etichetta contiene l'input.

Questo ha senso poiché in questo caso lo spazio è solo un altro personaggio dell'etichetta.

<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>

Essere in grado di fare clic tra etichetta e scatola significa che è:

• più facile da cliccare
• meno chiaro dove le cose iniziano e finiscono

Gli esempi della casella di controllo v3.3 Bootstrap usano l'input all'interno: http://getbootstrap.com/css/#forms Potrebbe essere saggio seguirli. Ma hanno cambiato idea in v4.0 https://getbootstrap.com/docs/4.0/components/forms/#checkboxes-and-radios, quindi non so più cosa sia saggio:

Le caselle di controllo e le radio utilizzate sono create per supportare la convalida dei moduli basata su HTML e fornire etichette concise e accessibili. Come tale, i nostri <input>s <label>sono elementi di pari livello rispetto a <input>all'interno di un <label>. Questo è leggermente più dettagliato in quanto è necessario specificare id e affinchè gli attributi mettano in relazione <input>e <label>.

Domanda sulla UX che discute in dettaglio questo punto: /ux/23552/should-the-space-b Between - the - checkbox - and - label - be - clickable

Personalmente mi piace tenere l'etichetta all'esterno, come nel tuo secondo esempio. Ecco perché l'attributo FOR è lì. Il motivo è che spesso applicherò stili all'etichetta, come una larghezza, per ottenere un aspetto gradevole del modulo (abbreviazione di seguito):

<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" />

Fa in modo che io possa evitare i tavoli e tutta quella roba indesiderata nelle mie forme.

Vedi http://www.w3.org/TR/html401/interact/forms.html#h-17.9 per le raccomandazioni W3.

Dicono che può essere fatto in entrambi i modi. Descrivono i due metodi come espliciti (usando "for" con l'id dell'elemento) e impliciti (incorporando l'elemento nell'etichetta):

Esplicito:

L'attributo for associa esplicitamente un'etichetta a un altro controllo: il valore dell'attributo for deve essere uguale al valore dell'attributo id dell'elemento di controllo associato.

Implicito:

Per associare implicitamente un'etichetta a un altro controllo, l'elemento di controllo deve trovarsi all'interno del contenuto dell'elemento LABEL. In questo caso, l'ETICHETTA può contenere solo un elemento di controllo.

Entrambi sono corretti, ma l'inserimento dell'input all'interno dell'etichetta lo rende molto meno flessibile durante lo styling con CSS.

Innanzitutto, a <label>è limitato in quali elementi può contenere . Ad esempio, puoi solo inserire un testo <div>tra <input>e il testo dell'etichetta, se <input>non è all'interno di <label>.

In secondo luogo, mentre ci sono soluzioni alternative per rendere più semplice lo stile come avvolgere il testo dell'etichetta interna con un arco, alcuni stili verranno ereditati dagli elementi padre, il che può rendere lo stile più complicato.

Un 'gotcha' notevole impone che non si debba mai includere più di un elemento di input all'interno di un elemento <label> con un attributo esplicito "for", ad esempio:

<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>

Sebbene ciò possa essere allettante per le funzionalità del modulo in cui un valore di testo personalizzato è secondario rispetto a un pulsante di opzione o casella di controllo, la funzionalità di attivazione del clic dell'elemento etichetta attiverà immediatamente l'elemento il cui ID è esplicitamente definito nell'attributo 'for' , rendendo quasi impossibile per l'utente fare clic nel campo di testo contenuto per inserire un valore.

Personalmente, provo a evitare gli elementi dell'etichetta con i figli di input. Sembra semanticamente improprio che un elemento etichetta includa più dell'etichetta stessa. Se stai annidando gli input nelle etichette per ottenere una certa estetica, dovresti invece usare CSS.

Come molte persone hanno detto, in entrambi i modi funzionano davvero, ma penso che solo il primo dovrebbe funzionare. Essendo semanticamente rigoroso, l'etichetta non "contiene" l'input. Secondo me, la relazione di contenimento (genitore / figlio) nella struttura di markup dovrebbe riflettere il contenimento nell'output visivo . cioè, un elemento che circonda un altro nel markup dovrebbe essere disegnato attorno a quello nel browser . In base a ciò, l'etichetta dovrebbe essere il fratello dell'input, non il genitore. Quindi l'opzione numero due è arbitraria e confusa. Chiunque abbia letto lo Zen di Python sarà probabilmente d'accordo (Flat è meglio di nidificato, Sparse è meglio di denso, Dovrebbe esserci uno - e preferibilmente solo un - modo evidente per farlo ...).

A causa di decisioni come quelle del W3C e dei principali fornitori di browser (che consentono "qualunque sia il modo in cui preferisci farlo", invece di "farlo nel modo giusto") è che il Web è così incasinato oggi e noi sviluppatori dobbiamo fare i conti con e così diverso codice legacy.

Di solito vado con le prime due opzioni. Ho visto uno scenario in cui è stata utilizzata la terza opzione, quando le scelte radio erano incorporate nelle etichette e nei CSS contenevano qualcosa di simile

label input {
    vertical-align: bottom;
}

al fine di garantire un corretto allineamento verticale delle radio.

Facendo riferimento a WHATWG ( Scrivere l'interfaccia utente di un modulo ) non è sbagliato inserire il campo di input all'interno dell'etichetta. Ciò consente di risparmiare codice perché l' forattributo da labelnon è più necessario.

Preferisco di gran lunga avvolgere gli elementi dentro di me <label>perché non devo generare gli ID.

Sono uno sviluppatore Javascript e React o Angular vengono utilizzati per generare componenti che possono essere riutilizzati da me o da altri. Sarebbe quindi facile duplicare un ID nella pagina, portando lì a comportamenti strani.

Una cosa da considerare è l'interazione della casella di controllo e degli ingressi radio con javascript.

Utilizzando la struttura sottostante:

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

Quando l'utente fa clic sulla funzione controlCheckbox () "Etichetta testo" verrà attivata una volta.

Ma quando si fa clic sul tag di input, la funzione controlCheckbox () può essere attivata due volte in alcuni browser meno recenti. Questo perché sia ​​i tag di input che quelli di etichetta attivano l'evento onclick associato alla casella di controllo.

Quindi potresti avere alcuni bug nella tua casella di controllo Stato.

Ho riscontrato questo problema di recente su IE11. Non sono sicuro se i browser moderni abbiano problemi con questa struttura.

Il vantaggio principale di collocare inputall'interno dilabel è la tipizzazione dell'efficienza per l'uomo e l'archiviazione dei byte per i computer.

@Znarkus ha detto nel suo commento all'OP,

Uno dei grandi pro di mettere <input />dentro l' interno <label>è che puoi omettere fore id: <label>My text <input /></label>nel tuo esempio. Molto più bello!

Nota: nel codice @Znarknus è stata inclusa un'altra efficienza non esplicitamente dichiarata nel commento. type="text"può anche essere omesso e inputvisualizzerà una casella di testo per impostazione predefinita.

Un confronto fianco a fianco di sequenze di tasti e byte [1].

31 sequenze di tasti, 31 byte

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

58 battute, 58 byte

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

Altrimenti, i frammenti sono visivamente uguali e offrono lo stesso livello di accessibilità dell'utente. Un utente può fare clic o toccare l'etichetta per posizionare il cursore nella casella di testo.

[1] File di testo (.txt) creati in Blocco note su Windows, byte dalle proprietà di Esplora file di Windows