Label for attribute?

[Samuël van Laere]

When I markup a form I allways use the label tag and use its for attribute.

Now I did a test with and without the for attribute and both seem to
work equally well:
http://webkluns.nl/form.html

Any pointers about when its needed to use the for attribute and when not?


cheers,
Samuël

 

[Jukka K. Korpela]

When I markup a form I allways use the label tag and use its for attribute.

Now I did a test with and without the for attribute and both seem to
work equally well:
http://webkluns.nl/form.html

Any pointers about when its needed to use the for attribute and when not?

By the specifications, the for attribute is not needed, if the <input>
element is nested inside the <label> element.

Some old browsers (IE up to IE 6) supported only the explicit
association via for and id attributes, not association via nesting of
elements.

Using for and id attributes for associating labels with fields is good
practice. Although IE 6 is virtually ignorable now, it is not quite
logical to put a field inside its label. Moreover, if you organize your
form fields in a table, putting labels in one column and fields in
another, you cannot nest them that way.

 

[Samuël van Laere]

Op 10-8-2012 10:29, Jukka K. Korpela schreef:

Using for and id attributes for associating labels with fields is good
practice. Although IE 6 is virtually ignorable now, it is not quite
logical to put a field inside its label. Moreover, if you organize your
form fields in a table, putting labels in one column and fields in
another, you cannot nest them that way.

Since i'm curious:
why is it not logical to have a input inside a label?

Or why is this (more) logical?:
<label for="pdc1">Dell</label><input name="pdc1" value="1" id="pdc1"
type="checkbox">

Thanks for the input so far Jukka.

cheers,
Samuel

 

[Jukka K. Korpela]

why is it not logical to have a input inside a label?

Because an input field (control) is an element that exists in order to
accept user input, whereas a label element specifies a textual
explanation for an input field. So an input is not logically a part (a
component) of a label.

Or why is this (more) logical?:
<label for="pdc1">Dell</label><input name="pdc1" value="1" id="pdc1"
type="checkbox">

Here the label and the input are two separate elements, though coupled
using the attributes. Only the text "Dell" is designated as the label.

 

[Samuël van Laere]

Op 10-8-2012 11:26, Jukka K. Korpela schreef:

Because an input field (control) is an element that exists in order to
accept user input, whereas a label element specifies a textual
explanation for an input field. So an input is not logically a part (a
component) of a label.


Here the label and the input are two separate elements, though coupled
using the attributes. Only the text "Dell" is designated as the label.

It makes sence yes, thank you Jukka.

Does it matter in which order the tags are markedup?:
<label for="pdc1">Dell</label><input name="pdc1" value="1" id="pdc1"
type="checkbox">
Or:
<input name="pdc1" value="1" id="pdc1" type="checkbox"><label
for="pdc1">Dell</label>

cheers,
Samuel

 

[Jukka K. Korpela]

Does it matter in which order the tags are markedup?:
<label for="pdc1">Dell</label><input name="pdc1" value="1" id="pdc1"
type="checkbox">
Or:
<input name="pdc1" value="1" id="pdc1" type="checkbox"><label
for="pdc1">Dell</label>

It matters. Both ways are possible, but the latter (checkbox first) is
much more common and therefore works better - people are used to it.
There is a recent thread on this in the WebAIM mailing list, from the
viewpoint of accessibility:
http://webaim.org/discussion/mail_thread?thread=5441

 

[Thomas Mlynarczyk]

Jukka K. Korpela schrieb:
[why is it not logical to have a input inside a label?]

Because an input field (control) is an element that exists in order to
accept user input, whereas a label element specifies a textual
explanation for an input field. So an input is not logically a part (a
component) of a label.

While this is correct, it raises the question why the W3C chose to allow
the nested variant then. It would have been more logical to make the
label an attribute of the input field.

On the other hand, both the label and the input field together form a
semantic unit, so it would be good if there was an element like,
perhaps, <formfield> which could contain an input element (or even
several) as well as its (their) label.

Greetings,
Thomas

 

[Jukka K. Korpela]

Jukka K. Korpela schrieb:
[why is it not logical to have a input inside a label?]

Because an input field (control) is an element that exists in order to
accept user input, whereas a label element specifies a textual
explanation for an input field. So an input is not logically a part (a
component) of a label.

While this is correct, it raises the question why the W3C chose to allow
the nested variant then.

Indeed. It seems to add to the complexity of the language - not much,
but without any gain except minor convenience in authoring. Anyway, HTML
4.01 presents the explicit association first and uses it in all examples.

It would have been more logical to make the
label an attribute of the input field.

In a sense yes, and for <input type=submit> and <input type=button>, it
_is_ possible: the value="..." attribute acts as a label. The HTML 4.01
spec even refers them as labels:
"Some form controls automatically have labels associated with them
(press buttons) while most do not (text fields, checkboxes and radio
buttons, and menus)."
http://www.w3.org/TR/html401/interact/forms.html#h-17.9

But extending such usage would extend the questionable use of attributes
to carry content. On the practical side, it would limit labels to plain
text - which is often mentioned as a problem with buttons.

On the other hand, both the label and the input field together form a
semantic unit, so it would be good if there was an element like,
perhaps, <formfield> which could contain an input element (or even
several) as well as its (their) label.

Yes, that would be natural. But then something else (like association
with for and id attributes) would still be needed in cases where the
label and the input field cannot be wrapped in the same container (e.g.,
when they are in different columns of a table).