Why Your Form Checkboxes Need to Have Label Tags
uxmovement.com
uxmovement.com
Labels don't have to wrap inputs. In fact, mine almost never do, that's too much of a pain to align. They're usually linked to their input via @for (and at some point in the future, I'll be able to do that with inputs and forms via @form, what a glorious day that will be)
I was on a site the other day, I can't remember where but it was "Fortune 500" level stuff and they didn't have checkbox labels. It amazes me how much this gets missed.
Nice little usability rant: http://theoatmeal.com/comics/shopping_cart
Example:
- Search Box Below
- Everything is a table - <FONT> everywhere - URLs on self-posts doesn't convert into a link - Un-upvote/downvote
But there is no need to always use id="xx" in the input and for="xx" in the label. 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.
i.e.:
<LABEL><INPUT type="checkbox" name="foo">Include bar?</LABEL>
<INPUT type="checkbox" name="foo" id="foo"><LABEL for="foo">Include bar?</LABEL>
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)
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.
http://www.w3.org/TR/html4/interact/forms.html#h-17.9.1
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>
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.
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.
But the "fast" thing to do is to add the long form declaration of the label into your templating function library.
In the future it would be much quicker to write something like: print checkbox('foo')
And get the 'fool proof': <INPUT type="checkbox" name="foo" id="foo"><LABEL for="foo">Include bar?</LABEL>
as output.
Also names can repeat, either within the same form (radio boxes for example, but other elements too), or in different forms. IDs cannot, and must be unique.
And you can get that with any form field type.
Now you say "well you're using a cool form library, so it can just make ids unique per form and you get "checkbox1", "checkbox2", ..."
Except ids are unique per page, you could very well have a thousand forms with the exact same names in them, and you'll still need all of those inputs to have different ids.
All of your criticisms apply equally to the technique it replaces.
Now since however, I didn't really specify what went into the checkbox function behind the scenes... lets assume.
1. It creates unique id variations. 2. It handles the case where you have multiple checkboxes with the same name. Perhaps by passing in differing parameters (e.g. checkbox(id='?', name='foo')).
You're criticizing an unspecified strawman example. Until someone actually goes out and writes this library, neither you nor I know how 'fool proof' it really is and what edge cases it leaves unspecified.
Almost all of them are bots anyway.
Ironically enough, blind people who use screen readers might see a very good reason.
And anyway JAWS use IE to read the page for the user, so it does support javascript.
No wonder people are complaining so much about HN.
Edit: Down votes? For trying to remind the community about the high quality of content and discussions on HN 2 years ago. OK.
Especially considering that your comment isn't grayed out at all right now.
It is so much easier to read and understand.