[whatwg] LABEL and radio/checkbox onclick

[James Graham]

Matthew Raymond wrote:

> James Graham wrote:
>
>> Matthew Raymond wrote:
>>
>>> Matthew Thomas wrote:
>>>
>>>>>    A <label> element is semantically worthless without an 
>>>>> associated  control, because, fundamentally, a label actually has 
>>>>> to label  something.
>>>>
>>>>
>>>> Similarly, a heading has to be a heading for something. And 
>>>> similarly,  the <h1>-<h6> elements don't require you to specify 
>>>> exactly what part  of a document they are a heading for. Worse, 
>>>> unlike <label>, with  <h1>-<h6> you can't do so even if you want to.
>>>
>>>
>>>    I should point out that I hate the heading elements. They serve no
>>> practical purpose other than formatting, 
>>
>>
>> If used properly, they can be used to construct a document outline. I 
>> agree that they're not that well designed although they do offer a 
>> little flexibility not found in the XHTML 2 model. But this is way 
>> off topic.
>
>
>    In theory, they can be used to construct a document outline. In 
> practice, they could be replaced by <span> or <font> elements and 99% 
> of the time no one would know the difference.

Ditto for almost every non-replaced semantic element. For the 99% of 
people who use visual browsers, there is very little I can think of that 
can't be replaced by <span> or <font> - even <a> elements can be (and 
often are) <font onclick="popupWindow();"> most of the time. I suppose 
support for <acronym> is an example of the most popular visual browsers 
making use of semantic elements. If we're arguing at the 99% level, 
semantics are irrelevant and everything since html 3.2 has been a step 
backwards.

Personally, I use a document outlining tool and, on the sites which use 
headings, it works quite well. If they use heading levels to provide 
structure, it's exceptionally useful. Fortunatley, it is often documents 
that most need an outlining tool (e.g. W3C specs) that use headings 
best. Of course some sites (Google springs to mind) use miserable HTML. 
In those cases, I (as a user of a visual UA) am lucky eneough to be able 
to infer the structure anyway and so I only loose a little convenience.

Do you seriously believe semantics are worthless?

>
>>>     I generally agree, but, with regards to <label>, the only issue is
>>> that the spec writers neglected to use the word "must". Otherwise, the
>>> semantics of <label> and how to make an association with a control are
>>> spelled out clearly.
>>
>>
>> The assosiation between label and control is primarilly so that users 
>> of non-visual UAs can tell which label goes with which control.
>
>
>    This is revisionist. Clearly, the spec intends for the association 
> to be used for focus passing, especially with regard to passing the 
> focus that's caused by access keys.

The HTML 4 spec clearly does intend that. It says so. But that doesn't 
mean it's the primary motivation behind a label/control association. 
Without explicit <label>s for controls, a UA cannot determine which 
label goes with which control. This is a disaster for non-visual UAs. 
Since HTML4 is specifically designed to work on non-visual UAs I find it 
difficult to believe that focus passing was the primary motivation and 
semantics was a happy accident. If this did happen to be the case, I 
regard the justifcation as wrongheaded and the happy accident as the 
useful feature. It's also mentioned in "HTML techniques for web content 
accessibility guidelines 1.0" [1]

A quick search of www-html didn't turn up any justifcation for the 
<label>/control association.

> Furthermore, I did a quick test of Mozilla, IE and Opera on my system, 
> and none of them associated a <label> with the nearest control (with 
> regard to focus passing) in cases where the documented association 
> methods were not used.

So?

>
>>>>>> I really don't understand why you _want_ labels to do the wrong 
>>>>>> thing.
>>>>>
>>>>>
>>>>>    Wrong as defined by whom?
>>>>
>>>>
>>>> As defined by the vendors of GUI toolkits for the past 20 years,
>>>
>>>
>>>    The logic here is flawed. It assumes both that GUI API and toolkit
>>> developers are infallible,
>>
>>
>> No, it assumes that changes to the toolkit should be made at toolkit 
>> level. HTML provides a means for specifying the structure of the 
>> toolkit elements (in a form or application), not the toolkit itself. 
>> Either complain to toolkit vendors or wait for XBL to be widely 
>> deployed so you can create your own non-native toolkit and confuse 
>> users all you want.
>
>
>    This is working under the false assumption that browsers use OS API 
> or toolkit widgets, which is not the case for Internet Explorer and 
> Mozilla, which use custom widgets. Changes to browsers with custom 
> widgets would be necessary in order to support changes to the behavior 
> defined in HTML 4.01.

It works under the assumption that the custom widgets should be 
indistinguishable from native widgets on the same platform to the extent 
that is possible.

>>> It also
>>> assumes that many elements of the GUIs were the result of conscious,
>>> thorough and intentional decision making, which you do not produce
>>> evidence for.
>>
>>
>> And you did not produce evidence against. (actually I did produce 
>> circumstantial evidence in favour of the position this was a decision 
>> rather than negligence but that's hardly conclusive).
>
>
>    Why should I produce evidence when I'm not the one who wants to 
> make a change to a five year old behavior supported by the majority of 
> HTML4 browsers?

(tangentially: we're not talking about browsers here, we're talking 
about the design decisions in GUI toolkits. Your argument that it's OK 
to add new behaviors rests on this fact but you seem to have ignored 
that here)

Practically? Because the WHAT specs disagree with your position. More 
importantly, because one should always be able to challenge old 
assumptions and old models and, if one is to retain them, show that the 
original justifcation for those models is still valid or is superseeded 
by new arguments that ensure the correct choice is still being made.

If you don't have any evidence in favor of the position that GUI 
designers (on all platforms) ignored the possibility that <label>-like 
elements could have behavior, I don't see the point in responding to 
arguments based on that premise (I also don't think it's a premise that 
leads to your conclusion that it's OK to make label behave in any way we 
like independent of the platform)

> Remember that we're talking about a behavior that replaces the absence 
> of a behavior, so you need to argue not only that the platform 
> developers specifically chose to exclude it, but were opposed to other 
> vendors adding the functionality to their programs.

Read a HIG document. One of the primary messages they seek to 
communicate is "don't invent your own GUI conventions". I've never heard 
from a UI person who didn't believe that consistency was of paramount 
importance in making easy-to-use interfaces.

>>>    (Interestingly, there also seems to be the implication that the
>>> browser shouldn't be a platform in itself. I'd be interested in hearing
>>> people's opinions on this...)
>>
>>
>> The browser shouldn't be a platform in itself. We have enough 
>> platforms. I think jwz was wrong;  these days just reading email 
>> isn't enough, every piece of software expands until it's a 
>> general-purpose platform. HTML is only a "platform" in the rather 
>> limited sense described above; i.e. it allows native (or native-like) 
>> widgets to be arranged and allows scripting of events triggered when 
>> the user navigates those elements.
>
>
>    I don't really support HTML as its own platform either (although 
> I'd be interested in seeing an OS where the GUI is based entirely on a 
> superset of HTML or similar). However, I don't necessarily agree with 
> reducing HTML functionality to a subset of the native platform. If an 
> OS doesn't have the GUI elements necessary for proper use of web pages 
> and applications, the vendors should not be prevented from 
> implementing custom widgets and behavior to address the problem. There 
> is a line where that could go to far, and vendors could end up 
> creating platforms and confusing users, but I don't believe that 
> <label>, in its current form, crosses that line.

Elements with the functionality of <label> already exist on every 
platform I've ever used (controls have labeling text). I have no idea 
whether, at the toolkit level, they are similar but, as a user, I don't 
expect to have to know the details of particular toolkits in order to 
predict the behavior of users.

We're talking about UI here. You *have to* look at the problem from the 
user's perspective. That means arguments based on the toolkit code are 
invalid.

>
>> It is entirely reasonable that the behavior is different because, 
>> from the point of view of the user, the actions of using an accesskey 
>> and clicking a label are different.
>
>
>    Not really. Invoking the access key gives focus to the control

Users don't know or care which elment the accesskey is defined on. They 
might know that where a control label has an underlined letter alt+that 
letter will focus the control.

>> The only change that is really needed is that, when an accesskey 
>> specified on a label is used, the focus goes directly to the control 
>> rather than passing through the label.
>
>
>    Actually, in the case of native focusing behavior, it would be 
> better to say that the access key is passed to the control...

That sounds quite reasonable. Ceryian controls don't support accesskeys 
so there might be a few technical details to sort out.

>>>>> Furthermore, look at the actual control in the example it refers to:
>>>>>
>>>>> <LABEL for="fuser" accesskey="U">User Name</LABEL>
>>>>> <INPUT type="text" name="user" id="fuser">
>>>>>
>>>>>    It's a TEXT BOX!!! Clearly, the focus passing behavior in the 
>>>>> spec  is intentional.
>>>>
>>>>
>>>> Sure, but that's (1) for accesskey, which is not the issue here,
>>>
>>>
>>>    It is the issue, because, according to the specification,
>>> |accesskey| give focus to the <label>, not the control. The <label> 
>>> give
>>> focus to the control through focus passing.
>>
>>
>> Since we're improving this anyway there's no need to rely on the HTML 
>> 4 behavior. I would be *very* surprised if any pages broke because 
>> the control label didn't generate any focus events when accesskeys 
>> were used, especially given that accesskeys are so rarely used in the 
>> wild.
>
>
>    I've heard this argument before. It doesn't matter if the page 
> breaks or not. Saying something is good because it doesn't cause the 
> heavens to open up and rain fire down upon us is a rather weak argument.

Saying something is good because it offers better consistency for the 
user and won't have backward compatibility issues is I believe, a 
perfectly reasonable argument.

>>>> The spec should just say "Typing a label's access key gives
>>>> focus to the control associated with the label."
>>>
>>>
>>>    What is implied in the HTML 4.01 spec is that all input is
>>> redirected to the associated control. Why else have |accesskey| on
>>> <label> and make the use of |accesskey| with <label> the recommended
>>> method? Due to the |for| attribute and its ability to allow multiple
>>> labels to be attached to the same control, it is clearly not as an
>>> alternative way of assigning an |accesskey| value to the control.
>>
>>
>> I don't understand the difference between the proposed solution and 
>> the behavior you describe. I believed that HTML 4 specified that 
>> accesskeys should be defined on labels for accessibility reasons; the 
>> label contains a description of the control that can be used to 
>> describe the behavior of the accesskey.  If the control has multiple 
>> labels and the accesskey is defined on the control, it is much more 
>> difficult to extract a description.
>
>
>    What's your point?


<label for="control">Label text</label>
<label for="control">For some reason this has a second label</label>
<input id="control" accesskey="c">

If a UA lists the accesskeys on a page and describes the function of 
each, how should we obtain a description for accesskey "c"? If you put 
the accesskey on the label it's obvious (and easier to parse):
<label for="control" accesskey="c">Label text</label>
<label for="control">For some reason this has a second label</label>
<input id="control">

> This wasn't the scenario I outlined anyway. In theory, each <label> 
> can have it's own access key, so multiple access keys can (indirectly) 
> give focus to the control.

Why would that be a good thing? Are you suggesting that accesskeys are 
supposed to always be defined on labels just so single elements han have 
multiple accesskeys?

>    Besides, in the situation you describe, the UA can simply use the 
> text of the first label

True. But that may not always work as expected.

> , or the contents of the |name| attribute.

That is unlikely to provide a good description.

>> The Gtk people would probably consider a patch!
>
>
>    Got the website or email for that?

http://www.gtk.org/ ? The bug tracker is http://bugzilla.gnome.org/

> > However,
>
>> in general, I would prefer native-looking form controls. Designers 
>> seem to disagree. In my experience styling form controls often (but 
>> not always) impairs the usability of a page.
>
>
>    I'm not arguing that native styling shouldn't be used as the 
> default. I'm just saying that webmasters will find a way to make a web 
> page look the way they want regardless of what styling requirements we 
> impose, so I don't see a point in making trying to make it nigh 
> impossible for them.

True.

>
> <>It is entirely true that XBL will allow people to shoot themselves 
> in the foot. However a significant difference is that user stylesheets 
> can override XBL bindings but cannot override the browser defaults 
> (well, in theory, users could build their own native-like widgets but 
> that's pretty unreasonable). Therefore it's important that the default 
> behavior from HTML alone is as intuitive and native-like as possible.
>
>>>    When this happens, a lack of flexibility in HTML elements may result
>>> in their disuse in favor of XBL2 widgets, resulting in a semantic
>>> deterioration of the web.
>>
>>
>> Unless XBL has changed beyond all recognition in the W3C, it's still 
>> possible to bind XBL to semantic elements e.g. I could bind my custom 
>> label element to all label tags. In the hands of responsible authors 
>> XBL doesn't lead to semantic degredation any more than CSS.
>
>
>    This is not entirely accurate. For instance, a UA for the blind may 
> still use CSS, and therefore the UA may also use XBL. In fact, XBL may 
> be a powerful tool for the blind if used correctly. As a result, this 
> UA may in fact render the post-XBL content rather than the actual 
> label, bypassing any semantic value of the <label> element.

But the semantics are in the fact that it's a <label> element. Because 
of this, blind users may turn off bindings on all <label> elements 
rather easilly. There's only a problem if people bind without regard for 
semantics e.g. bind <textareas> to <inputs> or <inputs> to <spans> (I'm 
not sure how form submission works with xbl so maybe for forms that are 
submitted it will always be possible to turn off the bindings. For form 
elements that are just used with js, this won't be possible but it's no 
worse than "dhtml" in this respect).

> <>
>
>>>>> If the native operating system has a specific style for labels 
>>>>> that  pass focus, do you override the <label> styling if a style 
>>>>> for  focus-passing labels isn't defined?
>>>>
>>>>
>>>> You probably need to specify whether by "do" you mean "should", 
>>>> "must",  or "can", and whether by "you" you mean "UA implementors" 
>>>> or "Web  authors".
>>>
>>>
>>>    Clearly, "you" can't be the webmaster, otherwise he/she wouldn't
>>> have left out the styling. As for the rest, you're overcomplicating the
>>> question. The bottom line is that you have a styling conflict with the
>>> generic <label> styling and the platform-specific styling that only
>>> occurs with specific controls. I was asking about a method of solving
>>> this conflict without regard for whether the specific method should be
>>> required in spec (which is a somewhat separate argument).
>>
>>
>> If some OS allows foucs passing on certian elements, the UA vendor 
>> should be free to implement that (as is the case at present). If 
>> those elements have a particular style, that should be applied by the 
>> UA. If the author defines some style for generic labels, the CSS 
>> cascade sorts out the style that actually finally gets applied. If 
>> the UA wishes to veto any author styles, that's OK too.
>
>
>    The problem with this scheme is that, no matter how the UA vendor 
> decides to handle native styling, the webmaster still can't define 
> separate styling for focus-passing and non-focus-passing labels. With 
> the old system, they're all focus passing, so there's no guessing 
> about how to style what.

Well the UA might implement a psudo-class (like 
label:-UA-focus-passing). This could be standardised in CSS. Otherwise, 
the author should be encouraged to go with the native form control 
style, especially when it is used to indicate differences in 
functionality to the user.

[1] http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-labels
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20040827/8f3ae6ce/attachment.htm>