[whatwg] LABEL and radio/checkbox onclick

[Mikko Rantalainen]

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[1] 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.


[1] 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.

-- 
Mikko