<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Matthew Raymond wrote:
<blockquote cite="mid412E8BA1.3010207@earthlink.net" type="cite">James
Graham wrote:
<br>
<blockquote type="cite">Matthew Raymond wrote:
<br>
<blockquote type="cite">Matthew Thomas wrote:
<br>
<blockquote type="cite">
<blockquote type="cite"> A <label> element is
semantically worthless without an associated control, because,
fundamentally, a label actually has to label something.
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
<br>
I should point out that I hate the heading elements. They serve no
<br>
practical purpose other than formatting, </blockquote>
<br>
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.
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
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.<br>
<br>
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.<br>
<br>
Do you seriously believe semantics are worthless?<br>
<blockquote cite="mid412E8BA1.3010207@earthlink.net" type="cite"><br>
<blockquote type="cite">
<blockquote type="cite"> I generally agree, but, with regards to
<label>, the only issue is
<br>
that the spec writers neglected to use the word "must". Otherwise, the
<br>
semantics of <label> and how to make an association with a
control are
<br>
spelled out clearly.
<br>
</blockquote>
<br>
The assosiation between label and control is primarilly so that users
of non-visual UAs can tell which label goes with which control.
<br>
</blockquote>
<br>
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.</blockquote>
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]<br>
<br>
A quick search of www-html didn't turn up any justifcation for the
<label>/control association.<br>
<blockquote cite="mid412E8BA1.3010207@earthlink.net" type="cite">
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.
<br>
</blockquote>
So?<br>
<blockquote cite="mid412E8BA1.3010207@earthlink.net" type="cite"><br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">I really don't understand why you
_want_ labels to do the wrong thing.
<br>
</blockquote>
<br>
Wrong as defined by whom?
<br>
</blockquote>
<br>
As defined by the vendors of GUI toolkits for the past 20 years,
<br>
</blockquote>
<br>
The logic here is flawed. It assumes both that GUI API and toolkit
<br>
developers are infallible,
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
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. <br>
<blockquote cite="mid412E8BA1.3010207@earthlink.net" type="cite">
<blockquote type="cite">
<blockquote type="cite">It also
<br>
assumes that many elements of the GUIs were the result of conscious,
<br>
thorough and intentional decision making, which you do not produce
<br>
evidence for.
<br>
</blockquote>
<br>
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).
<br>
</blockquote>
<br>
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?</blockquote>
(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)<br>
<br>
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. <br>
<br>
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)<br>
<blockquote cite="mid412E8BA1.3010207@earthlink.net" type="cite">
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.
<br>
</blockquote>
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.<br>
<blockquote cite="mid412E8BA1.3010207@earthlink.net" type="cite">
<blockquote type="cite">
<blockquote type="cite"> (Interestingly, there also seems to be
the implication that the
<br>
browser shouldn't be a platform in itself. I'd be interested in hearing
<br>
people's opinions on this...)
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
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.<br>
<br>
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. <br>
<blockquote cite="mid412E8BA1.3010207@earthlink.net" type="cite"><br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
Not really. Invoking the access key gives focus to the control</blockquote>
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.<br>
<blockquote cite="mid412E8BA1.3010207@earthlink.net" type="cite">
<blockquote type="cite">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.
<br>
</blockquote>
<br>
Actually, in the case of native focusing behavior, it would be
better to say that the access key is passed to the control...
<br>
</blockquote>
That sounds quite reasonable. Ceryian controls don't support accesskeys
so there might be a few technical details to sort out.<br>
<blockquote cite="mid412E8BA1.3010207@earthlink.net" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">Furthermore, look at the actual control
in the example it refers to:
<br>
<br>
<LABEL for="fuser" accesskey="U">User Name</LABEL>
<br>
<INPUT type="text" name="user" id="fuser">
<br>
<br>
It's a TEXT BOX!!! Clearly, the focus passing behavior in the spec
is intentional.
<br>
</blockquote>
<br>
Sure, but that's (1) for accesskey, which is not the issue here,
<br>
</blockquote>
<br>
It is the issue, because, according to the specification,
<br>
|accesskey| give focus to the <label>, not the control. The
<label> give
<br>
focus to the control through focus passing.
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
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.<br>
<blockquote cite="mid412E8BA1.3010207@earthlink.net" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">The spec should just say "Typing a
label's access key gives
<br>
focus to the control associated with the label."
<br>
</blockquote>
<br>
What is implied in the HTML 4.01 spec is that all input is
<br>
redirected to the associated control. Why else have |accesskey| on
<br>
<label> and make the use of |accesskey| with <label> the
recommended
<br>
method? Due to the |for| attribute and its ability to allow multiple
<br>
labels to be attached to the same control, it is clearly not as an
<br>
alternative way of assigning an |accesskey| value to the control.
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
<br>
What's your point?</blockquote>
<br>
<label for="control">Label text</label><br>
<label for="control">For some reason this has a second
label</label><br>
<input id="control" accesskey="c"><br>
<br>
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):<br>
<label for="control" accesskey="c">Label text</label><br>
<label for="control">For some reason this has a second
label</label><br>
<input id="control"><br>
<blockquote cite="mid412E8BA1.3010207@earthlink.net" type="cite"> 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.
<br>
</blockquote>
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?<br>
<blockquote cite="mid412E8BA1.3010207@earthlink.net" type="cite">
Besides, in the situation you describe, the UA can simply use the text
of the first label</blockquote>
True. But that may not always work as expected.<br>
<blockquote cite="mid412E8BA1.3010207@earthlink.net" type="cite">, or
the contents of the |name| attribute.
<br>
</blockquote>
That is unlikely to provide a good description.<br>
<blockquote cite="mid412E8BA1.3010207@earthlink.net" type="cite">
<blockquote type="cite">The Gtk people would probably consider a
patch!
<br>
</blockquote>
<br>
Got the website or email for that?
<br>
</blockquote>
<a class="moz-txt-link-freetext" href="http://www.gtk.org/">http://www.gtk.org/</a> ? The bug tracker is <a class="moz-txt-link-freetext" href="http://bugzilla.gnome.org/">http://bugzilla.gnome.org/</a><br>
<blockquote cite="mid412E8BA1.3010207@earthlink.net" type="cite">>
However,
<br>
<blockquote type="cite">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.
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
True. <br>
<blockquote cite="mid412E8BA1.3010207@earthlink.net" type="cite"><br>
<>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.
<br>
<br>
<blockquote type="cite">
<blockquote type="cite"> When this happens, a lack of flexibility
in HTML elements may result
<br>
in their disuse in favor of XBL2 widgets, resulting in a semantic
<br>
deterioration of the web.
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
<br>
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.
<br>
</></blockquote>
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).<br>
<blockquote cite="mid412E8BA1.3010207@earthlink.net" type="cite"><><br>
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">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?
<br>
</blockquote>
<br>
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".
<br>
</blockquote>
<br>
Clearly, "you" can't be the webmaster, otherwise he/she wouldn't
<br>
have left out the styling. As for the rest, you're overcomplicating the
<br>
question. The bottom line is that you have a styling conflict with the
<br>
generic <label> styling and the platform-specific styling that
only
<br>
occurs with specific controls. I was asking about a method of solving
<br>
this conflict without regard for whether the specific method should be
<br>
required in spec (which is a somewhat separate argument).
<br>
</blockquote>
<br>
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.
<br>
</blockquote>
<br>
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.
<br>
</></blockquote>
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.<br>
<br>
[1] <a class="moz-txt-link-freetext" href="http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-labels">http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-labels</a><br>
</body>
</html>