W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2004

[whatwg] LABEL and radio/checkbox onclick

From: Matthew Thomas <mpt@myrealbox.com>
Date: Thu, 22 Jul 2004 23:01:17 +1200
Message-ID: <74B283F0-DBCE-11D8-879A-000A95AD3972@myrealbox.com>
On 22 Jul, 2004, at 6:50 AM, Matthew Raymond wrote:
>
> Matthew Thomas wrote:
> ...
>> No, that was just an example. Another example would be accidentally  
>> demolishing a complicated discontiguous selection in a <select  
>> multiple> by pressing an arrow key, when all you really wanted to do  
>> was scroll the page.
>
>    How would focus passing affect this? You have to click on the  
> control to do the selection in the first place.

As should have been obvious from the example, you have since attempted  
to change focus to the page, so as to scroll it with the arrow keys.  
(You may even have used other focusable controls in the meantime.)

> ...
>> No, I did not say <label> should be forbidden for controls other than  
>> checkboxes and radiobuttons. I said that clicking on such a label  
>> should not focus the control on platforms where doing so is not  
>> native behavior (i.e. all of them).
>
>    For all practical purposes, the two are the same.

As I already said, that is not true.
<http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-July/ 
001424.html> ("Firstly, to identify...")

> You also fail to consider cases when the behavior is a non-conflicting  
> superset of the operating systems conventions.

As I already said, that is not true.
<http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-July/ 
001378.html> ("Users frequently click...")
<http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-July/ 
001423.html> ("And in brushed-metal ...")
<http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-July/ 
001445.html> ("By breaking people's...")

> ...
>> It does make sense if the UA is running on Windows or Mac OS, because  
>> Enter has done the same thing in native dialogs on both those  
>> platforms for the past 20 years.
>
>    Native dialogs are not the same as having multiple <form> elements.

Fortunately the pages where multiple <form>s (and more particularly,  
the submit buttons of multiple <forms>) are visible in the viewport  
simultaneously are very few.

> There are many situations where you might have more than one form on a  
> page, and not all of those forms have a submit button.

In some Web browsers the address field doesn't have a submit button  
either.

>  Furthermore, there are situations where you don't necessarily want  
> there to be a default button triggered by hitting enter.

I already said that, but did not mention it here because it was  
irrelevant.
<http://bugzilla.mozilla.org/show_bug.cgi?id=156683> ("This makes  
Google...")

>    So far as I can tell, this use of the "enter" key is not even  
> covered in the spec. It's just a common behavior added by UA vendors.  
> So, in this case, some clarification of how the "enter" key should be  
> handled with regards to forms may be appropriate.

<http://bugzilla.mozilla.org/show_bug.cgi?id=156683#c21>

>>> Semantically, labels should *always* have connection so some control  
>>> --
>> Sure, but this cannot always be reflected in HTML. The most common  
>> example would be a heading <label> for a set of radio buttons
>
>    This is invalid markup.

That is not true.
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"  
"http://www.w3.org/TR/html4/loose.dtd"><html><head><title>foo</ 
title><style type="text/css">label {font-family:  
sans-serif}</style></head><body><p>Ice cream for everybody!</p><form  
action="bar"><label>Flavor:</label> <input id="v" name="flavor"  
type="radio" value="v"><label for="v">Vanilla</label> <input id="s"  
name="flavor" type="radio" value="s"><label for="s">Strawberry</label>  
<input type="submit" value="Order"></form></body></html>

(Pre-emptive disclaimer against pointless nitpicking: The  
<label>Flavor:</label> is both valid and conformant. The rest of the  
code is valid, but I make no guarantee that it is conformant.)

> ...
>> (for which <fieldset> would usually be inappropriate).
>
>    Of course it's inappropriate, since <fieldset> uses <legend> for  
> its caption, not <label>.

No, I did not say <fieldset> used <label> for its caption. And it  
should not have been necessary for me to spell out the exact content  
model of <fieldset> for you to understand what I was referring to.

> ...
>> If the OS changes, then UAs on that OS can follow suit without  
>> causing accidents.
>
>    What accidents? Provide an actual case where some real person was  
> significantly inconvenienced by label focus passing.

Sorry, nowadays I'm not working at an Internet cafe any more; and even  
if I was, customers upset with unexpected browser behavior would be  
unlikely to volunteer their names, ages etc so I could post them to a  
public mailing list to satisfy you for another few hours. Nowadays I'm  
studying instead, and I have three important tests next week, so  
henceforth I will be unable to continue correcting your  
misinterpretations and answering your variations of the same basic  
questions.  So I'll close by observing, like Maciej Stachowiak did, how  
unbelievable it is that anyone objects so strongly to UAs being allowed  
to follow the native behavior of the environment in which they run.

-- 
Matthew Thomas
http://mpt.net.nz/
Received on Thursday, 22 July 2004 04:01:17 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:58:35 UTC