¿Debo poner elementos de entrada dentro de un elemento de etiqueta?

¿Hay una mejor práctica en relación con la anidación de labely inputelementos HTML?

forma clásica:

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

o

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

Desde w3: la etiqueta puede colocarse antes, después o alrededor del control asociado.

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

Tenga en cuenta que la tercera técnica no se puede usar cuando se usa una tabla para el diseño, con la etiqueta en una celda y su campo de formulario asociado en otra celda.

Cualquiera de los dos es válido. Me gusta usar el primer o segundo ejemplo, ya que te da más control de estilo.

yo prefiero

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

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

terminado

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

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

Principalmente porque hace que el HTML sea más legible. Y realmente creo que mi primer ejemplo es más fácil de diseñar con CSS, ya que CSS funciona muy bien con elementos anidados.

Pero es cuestión de gustos, supongo.

Si necesita más opciones de estilo, agregue una etiqueta span.

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

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

El código todavía se ve mejor en mi opinión.

Si incluye la etiqueta de entrada en la etiqueta de la etiqueta, no necesita usar el atributo 'for'.

Dicho esto, no me gusta incluir la etiqueta de entrada en mis etiquetas porque creo que son entidades separadas, que no contienen.

Diferencia de comportamiento: hacer clic en el espacio entre la etiqueta y la entrada

Si hace clic en el espacio entre la etiqueta y la entrada, se activa la entrada solo si la etiqueta contiene la entrada.

Esto tiene sentido ya que en este caso el espacio es solo otro carácter de la etiqueta.

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

Poder hacer clic entre la etiqueta y el cuadro significa que es:

• más fácil de hacer clic
• menos claro dónde comienzan y terminan las cosas

Los ejemplos de la casilla de verificación Bootstrap v3.3 usan la entrada que se encuentra en el interior: http://getbootstrap.com/css/#forms Puede ser prudente seguirlos. Pero cambiaron de opinión en v4.0 https://getbootstrap.com/docs/4.0/components/forms/#checkboxes-and-radios, así que ya no sé lo que es sabio:

Las casillas de verificación y el uso de radios están diseñados para admitir la validación de formularios basada en HTML y proporcionar etiquetas concisas y accesibles. Como tal, nuestros <input>s y <label>s son elementos de hermanos en lugar de un <input>plazo de un <label>. Esto es un poco más detallado ya que debe especificar id y para que los atributos relacionen el <input>y <label>.

Pregunta de UX que analiza este punto en detalle: /ux/23552/should-the-space-between-the-checkbox-and-label-be-clickable

Personalmente, me gusta mantener la etiqueta afuera, como en tu segundo ejemplo. Es por eso que el atributo FOR está ahí. La razón es que a menudo aplicaré estilos a la etiqueta, como un ancho, para que el formulario se vea bien (abreviatura a continuación):

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

Lo hace para poder evitar las tablas y toda esa basura en mis formularios.

Consulte http://www.w3.org/TR/html401/interact/forms.html#h-17.9 para ver las recomendaciones de W3.

Dicen que se puede hacer de cualquier manera. Describen los dos métodos como explícito (usando "for" con la identificación del elemento) e implícito (incrustando el elemento en la etiqueta):

Explícito:

El atributo for asocia explícitamente una etiqueta con otro control: el valor del atributo for debe ser el mismo que el valor del atributo id del elemento de control asociado.

Implícito:

Para asociar una etiqueta con otro control implícitamente, el elemento de control debe estar dentro del contenido del elemento LABEL. En este caso, la ETIQUETA solo puede contener un elemento de control.

Ambos son correctos, pero poner la entrada dentro de la etiqueta hace que sea mucho menos flexible al diseñar con CSS.

Primero, a <label>está restringido en qué elementos puede contener . Por ejemplo, solo puede poner un <div>entre el <input>texto de la etiqueta y, si <input>no está dentro del <label>.

En segundo lugar, si bien existen soluciones alternativas para facilitar el estilo, como ajustar el texto de la etiqueta interna con un espacio, algunos estilos se heredarán de los elementos principales, lo que puede hacer que el estilo sea más complicado.

Un 'gotcha' notable indica que nunca debe incluir más de un elemento de entrada dentro de un elemento <label> con un atributo explícito "for", por ejemplo:

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

Si bien esto puede ser tentador para las características de formulario en las que un valor de texto personalizado es secundario a un botón de opción o casilla de verificación, la funcionalidad de enfoque de clic del elemento de etiqueta arrojará inmediatamente el foco al elemento cuya identificación se define explícitamente en su atributo 'for' , lo que hace casi imposible que el usuario haga clic en el campo de texto contenido para ingresar un valor.

Personalmente, trato de evitar elementos de etiqueta con elementos secundarios de entrada. Parece semánticamente inapropiado que un elemento de etiqueta abarque más que la etiqueta misma. Si está anidando entradas en etiquetas para lograr una cierta estética, debería usar CSS en su lugar.

Como la mayoría de la gente ha dicho, ambas formas funcionan, pero creo que solo la primera debería. Siendo semánticamente estricto, la etiqueta no "contiene" la entrada. En mi opinión, la relación de contención (padre / hijo) en la estructura de marcado debe reflejar la contención en la salida visual . es decir, un elemento que rodea a otro en el marcado debe dibujarse alrededor de ese en el navegador . De acuerdo con esto, la etiqueta debe ser el hermano de la entrada, no su padre. Entonces la opción número dos es arbitraria y confusa. Todos los que hayan leído el Zen de Python probablemente estarán de acuerdo (Flat es mejor que anidado, Sparse es mejor que denso, debería haber una, y preferiblemente solo una, forma obvia de hacerlo ...).

Debido a decisiones como esa del W3C y de los principales proveedores de navegadores (permitiendo "la forma que prefieras", en lugar de "hacerlo de la manera correcta") es que la web está tan desordenada hoy y los desarrolladores tenemos que lidiar con problemas y un código heredado tan diverso.

Normalmente voy con las dos primeras opciones. He visto un escenario en el que se usaba la tercera opción, cuando las opciones de radio estaban incrustadas en etiquetas y el CSS contenía algo como

label input {
    vertical-align: bottom;
}

para asegurar una alineación vertical adecuada para las radios.

En referencia al WHATWG ( Escritura de la interfaz de usuario de un formulario ), no está mal poner el campo de entrada dentro de la etiqueta. Esto le ahorra código porque el foratributo del labelya no es necesario.

Prefiero encapsular elementos dentro de mi <label>porque no tengo que generar los identificadores.

Soy un desarrollador de Javascript, y React o Angular se utilizan para generar componentes que pueden ser reutilizados por mí u otros. Entonces sería fácil duplicar una identificación en la página, lo que llevaría a comportamientos extraños.

Una cosa que debe considerar es la interacción de las casillas de verificación y las entradas de radio con javascript.

Usando la siguiente estructura:

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

Cuando el usuario hace clic en "Etiqueta de texto", la función controlCheckbox () se activará una vez.

Pero cuando se hace clic en la etiqueta de entrada, la función controlCheckbox () puede activarse dos veces en algunos navegadores más antiguos. Esto se debe a que las etiquetas de entrada y etiqueta activan el evento onclick adjunto a la casilla de verificación.

Entonces puede tener algunos errores en su casilla de verificación Estado.

Me he encontrado con este problema últimamente en IE11. No estoy seguro si los navegadores modernos tienen problemas con esta estructura.

La principal ventaja de colocar inputdentro labeles la eficiencia de escritura para humanos y el almacenamiento de bytes para computadoras.

@ Znarkus dijo en su comentario al OP:

Una de las grandes ventajas de poner el <input />interior <label>es que puede omitir fory id: <label>My text <input /></label>en su ejemplo. Mucho mejor!

Nota: En el código @Znarknus, se incluyó otra eficiencia que no se indicó explícitamente en el comentario. type="text"también se puede omitir y inputmostrará un cuadro de texto de forma predeterminada.

Una comparación lado a lado de las pulsaciones de teclas y bytes [1].

31 pulsaciones de teclas, 31 bytes

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

58 pulsaciones de teclas, 58 bytes

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

De lo contrario, los fragmentos son visualmente iguales y ofrecen el mismo nivel de accesibilidad del usuario. Un usuario puede hacer clic o tocar la etiqueta para colocar el cursor en el cuadro de texto.

[1] Archivos de texto (.txt) creados en el Bloc de notas en Windows, bytes de las propiedades del Explorador de archivos de Windows