> The majority of the time you can just wrap the label tag around the input tag. It works great and is very fast to do.
Actually the majority of the time you do not do that, as it's a pain in the ass to correctly style for alignment. Even more so in a cross-browser fashion. Splitting them provides far more stylistic flexibility, and is — I think — more correct semantically.
It also makes for much simpler scripting, as you just need to dereference @for when handling a proxied action from the label to the input, if you have mixed situations you need to handle both, and the first case requires a filtered traversal of the label's children.
(the piece had numerous other failings I find more problematic than this: no names on controls, crummy and non-informative ids, and the UX of the blog itself which you mentioned: code as a picture instead of as text)
I've been doing this for years and have never had the slightest alignment issue. Example?
Or do you mean if the label and input are in different columns of a table - in that case, obviously split them. I'm talking when they are near each other.
And I totally disagree about the semantics. Wrapping the label is much more correct semantically - it says this input and these words are related.
I do not understand what you mean by "simpler scripting". Are you trying to make a special script action when they click the words? I wouldn't do that - make the action on the input element.
I think using an explicit "for" attribute is cleaner than bundling the control inside the label tag, as you can transparently position the label without worrying about parental boundaries. Take the typical case of a container label:
<LABEL>
First Name
<INPUT type="text" name="firstname">
</LABEL>
The problem is that when you position/style the label in your CSS, you're also (by default) positioning the inner INPUT. This is easy enough to adjust in CSS but I prefer my elements to have "honest boundaries". To me it's slightly ugly to have a container element (<label> in this case) contain a sub-element (<input> in this case), but have the sub-element drift outside the boundaries of the parent.
So I prefer my labels and their corresponding inputs to be decoupled in the sense that neither contains the other. Another (slight) advantage to this approach is that you can cleanly assign multiple labels to the same input control, though I'm not sure when you'd want or need to do so.
> And I totally disagree about the semantics. Wrapping the label is much more correct semantically - it says this input and these words are related.
No, it says the input is part of the label, which is obviously nonsense. The opposite would work, but it's not legal. The @for attribute says they are related.
> I do not understand what you mean by "simpler scripting". Are you trying to make a special script action when they click the words?
Not necessarily click, but hover for instance. What if hovering over a label gave meta-information on the related field? As I noted, getting the field matching a label (and getting *whether the label has a matching field at all) is much easier via @for, it's a trivial getElementById dereference of label/@for.
Actually the majority of the time you do not do that, as it's a pain in the ass to correctly style for alignment. Even more so in a cross-browser fashion. Splitting them provides far more stylistic flexibility, and is — I think — more correct semantically.
It also makes for much simpler scripting, as you just need to dereference @for when handling a proxied action from the label to the input, if you have mixed situations you need to handle both, and the first case requires a filtered traversal of the label's children.
(the piece had numerous other failings I find more problematic than this: no names on controls, crummy and non-informative ids, and the UX of the blog itself which you mentioned: code as a picture instead of as text)