[whatwg] LABEL and radio/checkbox onclick

[James Graham]

of Matthew Raymond wrote:
> James Graham wrote:
> 
>> Matthew Raymond wrote:
>>
>>> Chris Kaminski wrote:
>>>
>>>> And how many users know what a browser is?
>>>
>>>
>>>    They don't have to. The just need to know what the window that had
>>> the "Internet" in it looks like. My sister refuses to use Mozilla
>>> Firefox on the house computer because it's "different" from Internet
>>> Explorer. Similarly, people know what their browser looks like, even 
>>> if they don't know what it is.
>>
>>
>> They do have  to because many programs that aren't IE use IE to render 
>> parts of their interface (there are also programs that embed Mozilla 
>> and programs on Mac OS that use Webcore). "Is this program IE?" isn't 
>> a suffcient test for "will this program use HTML or native behavior".
> 
> 
>    Good point, although it ignores the fact that he said "browser" and
> not "HTML rendering engine". The ability to display HTML doe not
> necessarily make a program a browser.
> 
>    Increasingly, HTML will be used for common apps on systems that
> don't require high performance UIs. So consistency with the rest of the
> OS is a factor. It should be noted, however, that most operating systems
> don't have a label widget, they have text blocks that are, in some
> cases, called "labels". 

That's irrelevant to a discussion about UI - the user has no idea of 
what's implementable in different frameworks, they only know what 
happens when they interact with the computer.

> If the web developer wants one of theses blocks
> of text, a simple <span> is capable if giving the developer everything
> he/she needs.

Well, except the association between label and control that is so 
important to any type of assistive technology. This is *really* 
important, even for a visual UA (since the  HTML spec recommends that 
accesskeys are defined on labels rather than controls and  it's 
important to know which label/control an accesskey applies to). Using 
<span> in place of <label> is tag abuse at least as bad as using <table> 
to provide formatting.

>>>> lack of functionality is a design decision just as is functionality. 
>>>> Just as in an image, negative space has visual weight the same as
>>>> positive space. Two sides, same coin.
>>>
>>>
>>>    Hardly.  [...] Lack of functionality MIGHT be a choice, or it may 
>>> simply be an oversight.
>>
>>
>> So you admit that the word "hardly" is essentially just hyperbole.
> 
> 
>    I admit only that the lack of functionality cannot be assumed to be
> an intentional exclusion of such functionality.

Nor can it be assumed to be an oversight. In either case, the user 
doesn't care, she just requires her computer to be as intuitive to 
operate as possible, and that means the interface in different programs 
must be consistent.

>> It's
>> very clear that lack of a particular behavior, even one that some 
>> users find useful, is often a design choice;
> 
> 
>    How often? Which behaviors? 

I'm not sure that's relevant. It's certainly not clear how one could 
collect such numbers.

>> (lack of) focus follows mouse is an obvious example.
> 
> 
>    In some operating systems, this is a feature that can be turned on.
> In others, there may be utilities that allow you to have this
> functionality. 

However very few widely used window managers turn this on by default, 
presumably because users find it difficult. That's an example of a lack 
of behavior being a design choice, something  that you seem to believe 
is impossible.

>>> Functionality shouldn't be forbidden simply because the OS developers 
>>> didn't think to put it into the operating system.
>>
>>
>> You have provided no evidence that this particular example is actually 
>> a case of the human / computer interaction experts being negligient 
>> rather than their making a valid design choice.

In the case of focus and control labels, the evidence that people 
thought about this is that specific controls do allow focus passing. 
It's not conclusive but it's there. In any case, the specific case isn't 
so important as the principle that we shouldn't try to specify the 
details of UI which would otherwise depend on the UA and platform.

>    The second problem is that, in this case, you're requiring anyone
> who works on an HTML specification to know the motivations behind the OS
> conventions of every operating system in the Known Universe, plus
> predict the UI features of operating systems that don't even exist yet.

No, you're requiring that. I'm requiring that the spec doesn't require a 
specific UI behavior so that UAs may follow platform specific 
conventions and requirements.

> 
>> More importantly, you have failed to justify a markup language spec 
>> specifying the behavior of platform-specific widgets.
> 
> 
> Furthermore,
> because of the issue of backwards compatibility with HTML 4.01 compliant
> content and UAs, I shouldn't have to justify it.

I believe that a WF 2 compliant UA should be allowed to implement any 
behavior for <label> it sees fit. Some vendors may consider HTML 4 
compliance to be more important than platform conventions, others may 
value the user experience over spec compliance. Neither choice should be 
required.

> On the contrary, you
> should have to justify its removal, 

It specifies something (widget behavior) that is the domain of the UA. 
It prevents UAs from implementing widgets tat behave like native apps on 
many platforms, thereby making the user experience offered by HTML forms 
worse than it would be if this behavior was not specified.

> especially considering the fact that
> its removal will affect the functionality of legacy content.

How so? If this is true, UA vendors will probably opt for backward 
compatibility but that doesn't mean we should continue to require the 
old behavior since it violates the general principle that the details of 
widget and their behavior are UA specific.

>> If designers want to force a particular behavior they can do so using 
>> script (perhaps wrapped up in Web Controls objects).
> 
> 
>    Not if the user agent has Javascript disabled, and furthermore, this
> won't solve the problem of legacy content no longer functioning as
> specified in the previous HTML spec.

Lots of things don't function the way that the HTML 4 spec suggests they 
should. If the WF2 spec states that there is  no particular requirement 
for the focus behavior when labels are clicked, UA vendors will be able 
to do whatever they like, including retaining the old behavior. WF2 
pages that rely on this behavior will, however, be considered broken 
just like those that rely on some other UA-specific quirk are broken.

> 
>> Otherwise we have no business "innovating" GUIs without regard for the 
>> diversity of avaliable platforms and the standard behavior on each.
> 
> 
>    You can't expect people writing a web specification to have
> knowledge of every existing operating system.

That's my point. That is exactly why nothing should be specified. 
Because there is no possible way for us to determine the behavior that 
makes most sense in all UAs. I don't quite understand where you've got 
the idea that leaving these details to the UA makes it less likely that 
WF will make sense  on new or uncommon platforms. I think it's very 
likely to make it work better since vendors do have the knowledge of the 
specific OS they are targeting that we lack.

>>>> Other than that, though, I'm not seeing any big deal either way.
>>>
>>>
>>>    To me, it represents a larger case. If we try to add features to 
>>> web app markup that aren't in the OS, no matter how beneficial they 
>>> may be, will they be removed from the draft to serve OS conventions?
>>
>>
>> What sort of features do you have in mind? If these "features" mean 
>> redefining the behavior of platform-specific widgets for no particular 
>> reason then, yes, I would hope they are removed.
> 
> 
>    Then you would agree to, for instance, removing support for
> |ondblclick| from operating systems that don't support double-clicking.

How does an ondoubleclick event redefine any platform specific 
behaviors? It adds functionality and therefore I support it On the other 
hand, I disapprove of programmers abusing the event to alter widget 
behavior, but the platform HIG documents deal with that, not the 
markup/DOM specifications. I also disagree with programmers who create 
pages requiring these events to exist in order that the page to 
functions that doesn't mean the events themselves are inherently bad.

It's true that ondblclick doesn't make sense on OSs that don't have 
double clicks. In that case, I would expect that either any events 
defined in an ondblclick handler would be ignored (much like we have 
device specific CSS properties which are ignored by devices that don't 
support them) or it would be mapped to an event on that device which 
performs a similar role as double click on devices which do support it 
(e.g. apple + click on a one button mouse is equivalent to right click 
on a multibutton mouse when using a Mac. Therefore, on that platform, it 
makes sense that the two actions generate the same events. In practice 
they might not, I don't know).

>> If they're really new
>> features, it's hard to see how they can conflict with existing OS 
>> conventions or behaviors.
> 
> 
>    In Windows, clicking an icon the first time selects it. Clicking it
> a second time (but not double-clicking it) allows you to change the
> label. (And clicking the icon label in Windows passes focus, BTW.) If
> double-click didn't exist, you'd be renaming the icon. Now that's just
> in Windows. Think of all the possible behavioral differences possible in
>  all the various operating systems, including handhelds.

So you're saying that programmers who have to write their own DHTML 
widgets won't always be able to follow platform specific behaviors and 
using that to justify having WF2 widgets have unusual behaviors? That 
doesn't make sense; one of the major benefits of having predefined 
widgets is that they can be rendered in a way appropriate to the UA 
being used. If the UA authors care about usability, that includes 
following the platform guidelines. We certainly shouldn't try to specify 
away such advantages. (Slightly offtopic; DHTML widgets are a disaster 
for accessibility because the UA has no way of presenting an interface 
that makes sense on that platform) .

> Remember, every feature is a new feature at some point, and if even
> the lack of functionality can be considered a feature, than any new
> feature can potentially conflict with an existing OS "feature". In that
> regard, holding user agents to "a foolish consistency" with the OS
> limits UI innovation and prevents popular widgets that may no exist in
> the OS from being introduced on the web.

If there is some widget needed for WF2 that does not exist on the  OS, 
it is up to the UA vendor to find an implementation that makes as much 
sense as possible on the platform they are targeting. I don't see how 
that limits our ability to innovate. If we come up with some remarkable 
piece of new functionality it would certainly be good for the spec to 
provide an example of a possible interface but it shouldn't be normative.


-- 
"If anybody ever tells you that you’re using the language incorrectly, 
just yell 'prescriptive grammarian!' at the top of your voice and all 
the linguists in the building will run over and surround the guy... and 
then they’ll rough him up"