Czy należy umieszczać elementy wejściowe wewnątrz elementu etykiety?

Wolę

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

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

Over

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

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

Głównie dlatego, że sprawia, że HTML jest bardziej czytelny. I myślę, że mój pierwszy przykład jest łatwiejszy do stylizacji za pomocą CSS, ponieważ CSS działa bardzo dobrze z zagnieżdżonymi elementami.

Jeśli potrzebujesz więcej opcji stylizacji, Dodaj znacznik span.

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

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

Różnica w zachowaniu: kliknięcie w odstępie między etykietą a wejściem

Jeśli klikniesz na spację pomiędzy etykietą a wejściem, aktywuje wejście tylko wtedy, gdy etykieta zawiera wejście.

Ma to sens, ponieważ w tym przypadku przestrzeń jest tylko kolejnym znakiem etykiety.

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

Możliwość klikania między etykietą a pudełkiem oznacza, że jest to:

• łatwiej kliknąć
• mniej jasne, gdzie rzeczy początek i koniec

Bootstrap checkbox V3. 3 przykłady użyj wejścia wewnątrz: http://getbootstrap.com/css/#forms byłoby mądrze pójść za nimi. Ale zmienili zdanie w v4. 0 https://getbootstrap.com/docs/4.0/components/forms/#checkboxes-and-radios więc już Nie wiem co jest mądre:

Pola wyboru i radiotelefony są zbudowane tak, aby obsługiwać walidację formularzy w formacie HTML i zapewniać zwięzłe, dostępne etykiety. Jako takie nasze <input> s I <label> S są elementy siostrzane w przeciwieństwie do <input> w obrębie <label>. Jest to nieco bardziej zwięzłe, ponieważ musisz podać id i aby atrybuty odnosiły się do <input> i <label>.

Pytanie UX, które szczegółowo omawia ten punkt: https://ux.stackexchange.com/questions/23552/should-the-space-between-the-checkbox-and-label-be-clickable

Jeśli dodasz znacznik wejściowy do znacznika etykiety, nie musisz używać atrybutu 'for'.

To powiedziawszy, nie lubię dołączać znacznika wejściowego do moich etykiet, ponieważ myślę, że są one oddzielnymi, nie zawierającymi, encjami.

Osobiście lubię trzymać etykietę na zewnątrz, jak w twoim drugim przykładzie. Dlatego atrybut FOR istnieje. Dlatego często stosuję Style na etykiecie, jak szerokość, aby formularz wyglądał ładnie (Skrót poniżej): {]}

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

Sprawia, że mogę unikać tabel i wszystkich tych śmieci w moich formularzach.

Zobacz http://www.w3.org/TR/html401/interact/forms.html#h-17.9 dla zaleceń W3.

Mówią, że można to zrobić tak czy inaczej. Opisują one dwie metody jako jawne (używając" for " z identyfikatorem elementu) i niejawne (osadzając element w etykiecie):

Explicit:

Atrybut for kojarzy etykietę z inną kontrolką jawnie: wartość atrybutu for musi być taka sama jak wartość atrybutu id powiązanej z nim kontrolki element kontrolny.

Implicit:

Aby w sposób niejawny powiązać etykietę z inną kontrolką, element kontrolny musi znajdować się wewnątrz zawartości elementu etykiety. W takim przypadku etykieta może zawierać tylko jeden element kontrolny.

Oba są poprawne, ale umieszczenie danych wejściowych wewnątrz etykiety sprawia, że jest ona znacznie mniej elastyczna podczas stylizacji za pomocą CSS.

Po pierwsze, A <label> jest ograniczone, w jakich elementach może zawierać . Na przykład, można umieścić <div> pomiędzy <input> a tekstem etykiety, jeśli <input> nie znajduje się wewnątrz <label>.

Po drugie, chociaż istnieją obejścia ułatwiające stylizację, takie jak owijanie wewnętrznego tekstu etykiety span, niektóre style będą dziedziczone z elementów nadrzędnych, które mogą skomplikuj stylizację.

Znacząca 'gotcha' nakazuje, aby nigdy nie umieszczać więcej niż jednego elementu wejściowego wewnątrz elementu z wyraźnym atrybutem "for", np:

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

Chociaż może to być kuszące dla funkcji formularza, w których niestandardowa wartość tekstowa jest wtórna do przycisku radiowego lub pola wyboru, funkcja "kliknij-fokus" elementu etykiety natychmiast rzuci fokus na element, którego id jest wyraźnie zdefiniowane w atrybucie "for", co prawie uniemożliwia użytkownikowi kliknięcie do zawartego pola tekstowego, aby wprowadzić wartość.

Osobiście staram się unikać elementów etykiet z wejściami potomnymi. Wydaje się semantycznie niewłaściwe, aby element etykiety obejmował więcej niż samą etykietę. Jeśli zagnieżdżasz dane wejściowe w etykietach w celu uzyskania określonej estetyki, powinieneś używać CSS.

Jak większość ludzi powiedziała, oba sposoby rzeczywiście działają, ale myślę, że tylko pierwszy powinien. Ponieważ etykieta jest semantycznie ścisła, nie "zawiera" danych wejściowych. Moim zdaniem relacja przechowawcza (rodzic/dziecko) w strukturze znaczników powinna odzwierciedlać zabezpieczenie w wyjściu wizualnym. to znaczy, element otaczający Inny w znaczniku powinien być narysowany wokół tego w przeglądarce. Zgodnie z tym, etykieta powinna być rodzeństwem wejścia, a nie to rodzic. Więc opcja numer dwa jest dowolna i myląca. Każdy, kto przeczytał Zen Pythona prawdopodobnie się zgodzi (Flat jest lepszy niż zagnieżdżony, Sparse jest lepszy niż gęsty, powinien być jeden-a najlepiej tylko jeden-oczywisty sposób, aby to zrobić...).

Z powodu takich decyzji ze strony W3C i głównych dostawców przeglądarek (pozwalając "w jaki sposób wolisz to zrobić", zamiast "zrób to we właściwy sposób") jest to, że sieć jest tak popaprana dzisiaj i my programiści mamy do czynienia z z zaplątanym i tak różnorodnym kodem dziedziczenia.

Zazwyczaj wybieram dwie pierwsze opcje. Widziałem scenariusz, w którym użyto trzeciej opcji, gdy opcje radiowe były osadzone w etykietach i css zawierały coś w stylu

label input {
    vertical-align: bottom;
}

W celu zapewnienia prawidłowego ustawienia radiotelefonów w pionie.

Nawiązując do WHATWG (pisanie interfejsu użytkownika formularza) nie jest złe umieszczenie pola wejściowego wewnątrz etykiety. Zapisuje to kod, ponieważ atrybut {[0] } z {[1] } nie jest już potrzebny.

Zdecydowanie wolę zawijać elementy wewnątrz mojego <label>, ponieważ nie muszę generować identyfikatorów.

Jestem programistą Javascript, a React lub Angular są używane do generowania komponentów, które mogą być ponownie użyte przeze mnie lub innych. Następnie łatwo byłoby zduplikować identyfikator na stronie, prowadząc do dziwnych zachowań.

Jedną z rzeczy, które musisz wziąć pod uwagę, jest interakcja checkbox i wejść radiowych z javascript.

Używając poniższej struktury:

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

Gdy użytkownik kliknie na "tekst etykiety" funkcja controlCheckbox() zostanie wywołana raz.

Ale po kliknięciu znacznika wejściowego funkcja controlCheckbox() może być uruchomiona dwukrotnie w niektórych starszych przeglądarkach. Dzieje się tak, ponieważ zarówno znaczniki wejścia, jak i etykiety wyzwalają Zdarzenie onclick dołączone do pola wyboru.

Wtedy możesz mieć jakieś błędy w swoim checkboxState.

Ostatnio natknąłem się na ten problem na IE11. Nie jestem pewien, czy współczesne przeglądarki mają problemy z tą strukturą.

Podstawową zaletą umieszczenia input wewnątrz label jest wydajność pisania dla ludzi i przechowywanie bajtów dla komputerów.

@ Znarkus powiedział w komentarzu do OP,

Jedną z największych zalet umieszczania <input /> wewnątrz <label> jest to, że można pominąć for i id: <label>My text <input /></label> w twoim przykładzie. O wiele milszy!

Uwaga :w kodzie @ Znarknus uwzględniono inną wydajność, która nie została wyraźnie określona w komentarzu. type="text" może być również pominięte i input domyślnie wyrenderuje pole tekstowe.

Porównanie obok siebie naciśnięć klawiszy i bajtów [1].

31 klawiszy, 31 bajtów

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

58 klawiszy, 58 bajtów

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

W Przeciwnym Razie urywki są wizualnie równe i oferują ten sam poziom dostępności użytkownika. Użytkownik może kliknąć lub stuknąć etykietę, aby umieścić kursor w polu tekstowym.

[1] Pliki Tekstowe (.txt) utworzone w notatniku na Windows, bajty z pliku Windows Właściwości Eksploratora