[whatwg] LABEL and radio/checkbox onclick
mira at cc.jyu.fi
Tue Jul 20 06:58:19 PDT 2004
Matthew Thomas / 2004-07-20 12:51:
> On 20 Jul, 2004, at 8:47 AM, Matthew Raymond wrote:
>> Matthew Thomas wrote:
>>> Yes: nothing at all. Users frequently click on (what they
>>> assume to be) non-functional parts of a GUI or a Web page as
>>> a form of doodling, while they're reading or thinking of what
>>> to write. Such clicks unexpectedly changing focus could
>>> produce undesirable results. For example, clicking on the
>>> label for a single-line text field (which would be
>>> non-functional if it was a native app) shortly before typing
>>> Enter would accidentally submit the form.
>> Why would you be hitting enter while randomly clicking on
>> places on the form?
> I did not say "while typing Enter", I said "shortly before typing
> Enter". For example, someone may be absent-mindedly tapping at
> the (apparently neutral) area of the "To:", "CC:", and "BCC:"
> labels in a Webmail app while he tries to decide whether to add
> anything further to the message. He remembers something else he
> must write about, so he presses Enter to start a new paragraph.
> If <label> behaves like it does native apps, nothing happens --
> the textarea has lost focus, and no form element is focused, so
> nothing happens until he realizes his mistake. But if <label>
> behaved the way you wanted it to, one of the address entry fields
> would be focused, and since those are single-line text fields,
> pressing Enter would send the message prematurely.
So, the *real* problem is that UA sends form on pseudo-random
basis if user presses ENTER and to fix this, you think that label
should be forbidden for other controls but checkbox and radio
button? How about fixing the ENTER key issue, instead?
I agree that having ENTER to submit the form is a great feature in
some cases -- for example, when I use Google, I love to be able to
just hit enter to submit the form after entering the query. However,
if the form contains more single line inputs, or heaven forbit, a
textarea or two, then it definately does NOT make any sense to
submit the form with ENTER key. Especially, if the focus is in the
first input. Please, just allow label for all controls and allow
form author to drop those labels (perhaps allow for="none" so that
authors can still markup labels but explicitly define that those
shouldn't focus anything, not that I think that's a good idea).
Semantically, labels should *always* have connection so some control
-- I claim that best choice is to leave UA to decide which controls
should be focusable via label, though I still think that the correct
answer is that all elements are focusable via label.
 Most user agents submit the form if user presses ENTER while
focus is in a single line text input (text or password) but do not
send the form if focus is in textarea (to allow inputting enter as
data). Some user agents send the form if user presses ENTER while a
checkbox is focused, some other agents just toggle the checkbox.
Ditto for radio buttons. In addition to that, after ENTER key some
user agents submit the form just like the *first* submit button had
been pressed and some other UAs just submit the form as-is; none of
the submit buttons are successful. (Submitting the first submit
button is bad, because the form could be emulating MacOS, where
cancel button is before ok/commit button in native applications.
Enter would always select the cancelling actions!) If we start
"fixing" other issues related to ENTER triggered submits, please,
lets strictly define how that's supposed to work. For example, I'd
prefer submit buttons having additional attribute
'default="default"' which would tell the UA that *this* submit
button should be pressed if *some* shortcut to submit the form is
used. If multiple buttons have the attribute (error situation), the
first one should be used. If no button has this attribute set, ENTER
*should not* submit the form.
More information about the whatwg