Sollte ich Eingabeelemente in ein Beschriftungselement einfügen?

Question

Gibt es eine bewährte Praxis für die Verschachtelung von label y input HTML-Elemente?

klassische Weise:

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

oder

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

Answer 1

参照 http://www.w3.org/TR/html401/interact/forms.html#h-17.9 für die W3-Empfehlungen.

Sie sagen, es kann so oder so gemacht werden. Sie beschreiben die beiden Methoden als explizit (Verwendung von "for" mit der ID des Elements) und implizit (Einbettung des Elements in das Etikett):

Explizit:

Das for-Attribut verknüpft ein Label explizit mit einem anderen Steuerelement: Der Wert des for-Attributs muss mit dem Wert des id-Attributs des zugehörigen Steuerelements identisch sein.

Implizit:

Um ein Label implizit mit einem anderen Steuerelement zu verknüpfen, muss das Steuerelement innerhalb des Inhalts des LABEL-Elements liegen. In diesem Fall darf das LABEL-Element nur ein Steuerelement enthalten.

Answer 2

Beides ist richtig, aber wenn man die Eingabe innerhalb der Beschriftung platziert, ist sie bei der Gestaltung mit CSS viel weniger flexibel.

Primero, a <label> ist hinsichtlich der Elemente, die es enthalten kann, eingeschränkt . Sie können zum Beispiel nur eine <div> zwischen den <input> und der Beschriftungstext, wenn die <input> befindet sich nicht innerhalb der <label> .

Zweitens gibt es zwar Umgehungsmöglichkeiten, um die Formatierung zu vereinfachen, wie z. B. das Umschließen des inneren Beschriftungstextes mit einer Spanne, aber einige Stile werden von übergeordneten Elementen geerbt, was die Formatierung komplizierter machen kann.

3rd party edit

Nach meinem Verständnis html 5.2 Spezifikation für Label besagt, dass die Etiketten Content model es Phrasing content . Dies bedeutet, dass nur Tags, deren Inhaltsmodell die Formulierung von Inhalten ist <label> are allowed inside </label> .

Inhaltsmodell Eine normative Beschreibung, welche Inhalte enthalten sein müssen als Kinder und Nachkommen des Elements enthalten sein müssen.

Die meisten Elemente, die als Phraseninhalt kategorisiert sind, können nur Elemente enthalten, die selbst als Phrasierungsinhalt kategorisiert sind, keine Flussinhalte.

Answer 3

Ein bemerkenswerter "Fehler" besteht darin, dass Sie niemals mehr als ein Eingabeelement innerhalb eines <label>-Elements mit einem ausdrücklichen "for"-Attribut einschließen sollten, z. B:

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

Dies mag zwar für Formularfunktionen verlockend sein, bei denen ein benutzerdefinierter Textwert einem Optionsfeld oder einem Kontrollkästchen untergeordnet ist, aber die Klick-Fokus-Funktionalität des Label-Elements wird den Fokus sofort auf das Element lenken, dessen id explizit in seinem "for"-Attribut definiert ist, wodurch es für den Benutzer nahezu unmöglich wird, in das enthaltene Textfeld zu klicken, um einen Wert einzugeben.

Ich persönlich versuche, Beschriftungselemente mit Eingabekindern zu vermeiden. Es erscheint mir semantisch unangemessen, wenn ein Beschriftungselement mehr als nur die Beschriftung selbst umfasst. Wenn Sie Eingaben in Beschriftungen verschachteln, um eine bestimmte Ästhetik zu erreichen, sollten Sie stattdessen CSS verwenden.

Answer 4

Wie die meisten schon gesagt haben, funktionieren beide Wege, aber ich denke, nur der erste sollte funktionieren. Da das Etikett semantisch streng ist, "enthält" es die Eingabe nicht. Meiner Meinung nach ist die Einschlussbeziehung (Eltern/Kind) in der Markup-Struktur sollte die Eindämmung widerspiegeln in der visuellen Ausgabe . d.h. ein Element, das ein anderes umgibt im Markup sollte um diesen herum gezogen werden im Browser . Demnach sollte die Beschriftung ein Geschwisterteil der Eingabe sein, nicht ihr Elternteil. Option Nummer zwei ist also willkürlich und verwirrend. Jeder, der die Zen der Python werden wahrscheinlich zustimmen (flach ist besser als verschachtelt, spärlich ist besser als dicht, es sollte einen - und vorzugsweise nur einen - offensichtlichen Weg geben, es zu tun...).

Wegen solcher Entscheidungen des W3C und der großen Browserhersteller (die erlauben, dass man es so macht, wie man es am liebsten macht", anstatt es richtig zu machen") ist das Web heute so unübersichtlich und wir Entwickler müssen uns mit verworrenem und so unterschiedlichem Legacy-Code herumschlagen.

Answer 5

Ich entscheide mich in der Regel für die ersten beiden Optionen. Ich habe ein Szenario gesehen, wenn die dritte Option verwendet wurde, wenn Radio-Entscheidungen, wo in Etiketten eingebettet und die css etwas wie enthalten

label input {
    vertical-align: bottom;
}

um eine korrekte vertikale Ausrichtung der Funkgeräte zu gewährleisten.