Czy powinienem umieścić elementy wejściowe wewnątrz elementu etykiety?

Czy istnieje najlepsza praktyka dotycząca zagnieżdżania labeli inputelementów HTML?

klasyczny sposób:

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

lub

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

Od w3: Sama etykieta może być umieszczana przed, za lub wokół powiązanej kontrolki.

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

lub

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

lub

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

Należy zauważyć, że trzeciej techniki nie można użyć, gdy do układu używana jest tabela, z etykietą w jednej komórce i powiązanym polem formularza w innej komórce.

Każda z nich jest ważna. Lubię używać pierwszego lub drugiego przykładu, ponieważ daje on większą kontrolę nad stylem.

wolę

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

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

nad

<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 tak naprawdę uważam, że mój pierwszy przykład jest łatwiej stylizować za pomocą CSS, ponieważ CSS działa bardzo dobrze z zagnieżdżonymi elementami.

Ale to chyba kwestia gustu.

Jeśli potrzebujesz więcej opcji stylizacji, dodaj znacznik zakresu.

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

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

Moim zdaniem kod nadal wygląda lepiej.

Jeśli umieścisz tag wejściowy w tagu etykiety, nie musisz używać atrybutu „for”.

To powiedziawszy, nie lubię umieszczać tagu wejściowego w moich etykietach, ponieważ uważam, że są one osobnymi, nie zawierającymi bytów.

Różnica w zachowaniu: kliknięcie spacji między etykietą a danymi wejściowymi

Jeśli klikniesz spację między etykietą a danymi wejściowymi aktywuje dane wejściowe tylko wtedy, gdy etykieta zawiera dane wejściowe.

Ma to sens, ponieważ w tym przypadku spacja 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 polem oznacza, że ​​jest to:

• łatwiej kliknąć
• mniej jasne, gdzie wszystko się zaczyna i kończy

Przykłady pola wyboru Bootstrap v3.3 wykorzystują dane wejściowe: http://getbootstrap.com/css/#forms Mądrze może być ich przestrzeganie. Ale zmienili zdanie w wersji 4.0 https://getbootstrap.com/docs/4.0/components/forms/#checkboxes-and-radios, więc nie wiem już, co jest mądre:

Pola wyboru i radiotelefony są zbudowane tak, aby obsługiwać sprawdzanie poprawności formularzy oparte na HTML i zapewniać zwięzłe, dostępne etykiety. Jako takie, nasze <input>y i <label>y są elementy rodzeństwa, w przeciwieństwie do <input>W ciągu <label>. Jest to nieco bardziej szczegółowe, ponieważ musisz podać identyfikator i atrybuty, aby odnosić się do <input>i <label>.

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

Osobiście lubię trzymać etykietę na zewnątrz, jak w twoim drugim przykładzie. Właśnie dlatego istnieje atrybut FOR. Powodem jest to, że często stosuję style do etykiety, takie 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ę uniknąć stołów i innych śmieci w moich formularzach.

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

Mówią, że można to zrobić w obie strony. Opisują dwie metody jako jawne (użycie „for” z identyfikatorem elementu) i niejawne (osadzenie elementu w etykiecie):

Wyraźny:

Atrybut for jednoznacznie kojarzy etykietę z inną kontrolką: wartość atrybutu for musi być taka sama jak wartość atrybutu id powiązanego elementu kontrolnego.

Domniemany:

Aby skojarzyć etykietę z inną kontrolką w sposób niejawny, element kontrolny musi znajdować się w treści elementu LABEL. W takim przypadku ETYKIETA może zawierać tylko jeden element sterujący.

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

Po pierwsze, a <label>jest ograniczone, w których elementach może zawierać . Na przykład możesz wstawić <div>pomiędzy <input>tekstem a etykietą tylko, jeśli <input>nie ma go w środku<label> .

Po drugie, podczas gdy istnieją obejścia, które ułatwiają stylizację, takie jak zawijanie tekstu etykiety wewnętrznej za pomocą zakresu, niektóre style będą dziedziczone z elementów nadrzędnych, co może utrudnić stylizację.

Znana „gotcha” nakazuje, abyś nigdy nie zawierał więcej niż jednego elementu wejściowego wewnątrz elementu <label> 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 kusić dla funkcji formularza, w których niestandardowa wartość tekstowa jest drugorzędna względem przycisku opcji lub pola wyboru, funkcja skupienia kliknięcia elementu etykiety natychmiast przeniesie fokus na element, którego identyfikator jest wyraźnie zdefiniowany w atrybucie „for” , co prawie uniemożliwia użytkownikowi kliknięcie zawartego pola tekstowego w celu wprowadzenia wartości.

Osobiście staram się unikać elementów etykiet z potomkami wejściowymi. 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, aby osiągnąć określoną estetykę, powinieneś użyć CSS.

Jak większość ludzi powiedziała, oba sposoby rzeczywiście działają, ale myślę, że tylko pierwszy powinien. Będąc semantycznie ścisłym, etykieta nie „zawiera” danych wejściowych. Moim zdaniem relacja przechowująca (nadrzędna / podrzędna) w strukturze znaczników powinna odzwierciedlać powstrzymywanie w wynikach wizualnych . tzn. element otaczający inny element znacznika powinien zostać narysowany wokół tego elementu w przeglądarce . Zgodnie z tym etykieta powinna być rodzeństwem danych wejściowych, a nie nadrzędnym. Zatem opcja numer dwa jest arbitralna i myląca. Każdy, kto przeczytał Zen Pythona , prawdopodobnie się zgodzi (Płaski jest lepszy niż zagnieżdżony, Rzadki jest lepszy niż gęsty, Powinien być jeden - a najlepiej tylko jeden - oczywisty sposób, aby to zrobić ...).

Z powodu takich decyzji podejmowanych przez W3C i głównych dostawców przeglądarek (zezwalając na „jakikolwiek sposób, w jaki wolisz to zrobić”, zamiast „zrób to we właściwy sposób”), Internet jest dziś tak poplątany, a my programiści mamy do czynienia z zaplątanymi i tak różnorodny starszy kod.

Zwykle wybieram dwie pierwsze opcje. Widziałem scenariusz, w którym zastosowano trzecią opcję, gdy opcje radiowe, w których osadzone były w etykietach i css, zawierały coś podobnego

label input {
    vertical-align: bottom;
}

w celu zapewnienia właściwego ustawienia pionowego radiotelefonów.

Odnosząc się do WHATWG ( Pisanie interfejsu użytkownika formularza ), nie jest błędem umieszczenie pola wejściowego wewnątrz etykiety. Oszczędza to kod, ponieważ foratrybut z labelnie jest już potrzebny.

Bardzo wolę zawijać elementy w sobie, <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 wykorzystane przeze mnie lub innych. Łatwo byłoby zatem zduplikować identyfikator na stronie, prowadząc do dziwnych zachowań.

Jedną z rzeczy, które należy wziąć pod uwagę, jest interakcja pól wyboru i wejść radiowych z javascript.

Korzystanie z poniższej struktury:

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

Gdy użytkownik kliknie „Tekst etykiety”, funkcja controlCheckbox () zostanie uruchomiona jeden raz.

Ale po kliknięciu znacznika wejściowego funkcja controlCheckbox () może zostać uruchomiona dwukrotnie w niektórych starszych przeglądarkach. Jest tak, ponieważ zarówno tagi wejściowe, jak i etykiety wywołują zdarzenie onclick dołączone do pola wyboru.

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

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

Podstawową zaletą umieszczenia inputwewnątrzlabel jest wydajność pisania na klawiaturze dla ludzi i bajtowa pamięć dla komputerów.

@Znarkus powiedział w swoim komentarzu do OP:

Jedną z największych zalet umieszczenia w <input />środku <label>jest to, że możesz pominąć fori id: <label>My text <input /></label>w swoim przykładzie. O wiele ładniej!

Uwaga: W kodzie @Znarknus uwzględniono inną wydajność, która nie została wyraźnie określona w komentarzu. type="text"można również pominąć i inputdomyślnie wyświetla pole tekstowe.

Bezpośrednie porównanie naciśnięć klawiszy i bajtów [1].

31 klawiszy, 31 bajtów

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

58 naciśnięć klawiszy, 58 bajtów

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

W przeciwnym razie fragmenty są wizualnie równe i zapewniają ten sam poziom dostępności dla użytkowników. Użytkownik może kliknąć lub dotknąć etykiety, aby umieścić kursor w polu tekstowym.

[1] Pliki tekstowe (.txt) utworzone w Notatniku w systemie Windows, bajty z właściwości Eksploratora plików Windows