- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Mon, 02 Aug 2004 22:18:59 -0400
Matthew Thomas wrote:
> 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.)
This can happen even if you simply forgot to change the focus, and
it assumes the user both chooses to click on a label, that the user
doesn't know any better, and that there is no visual distinction between
a <label> element and text. This is, in part, a deficiency in the
multiple selection. Supplying a list with checkboxes instead of a
standard list fixes this problem completely.
Also, keep in mind, I'm not opposed to giving the user the ability
to distinguish between labels and text. For instance, radio button and
checkbox labels are styled with a dashed box when clicked in Windows,
and Windows XP highlights radio buttons and checkboxes when the mouse is
over their labels. Adding the OS conventions for radio button and
checkbox labels to the <label> control would easily clear up much user
confusion.
>>> 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...")
Saying it's not true doesn't make it so. If using OS conventions in
the way you would like them applied was required by WF2, is would
eliminate the feature from something like 99.999% of all browsers. The
fact that one browser on one obscure OS might allow focus passing is not
a practical concern, so the change to the HTML spec would effectively
result in feature removal.
>> 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...")
This it just the nervous click plus enter key scenario again, and
you have yet to produce a single individual this has actually happened
to. I'd also point out that you've failed to show why modification of
how the enter key is handled as opposed to <label> would not solve this
problem. Remember, the behavior of the enter key is not defined in the
HTML 4.01 specification, whereas the behavior of <label> is.
> <http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-July/
> 001423.html> ("And in brushed-metal ...")
This isn't a problem. First of all, it seems bad UI to have neutral
space in a web page allow the window to be dragged. How will the user
know if the window gets dragged or whether it will simply scroll the
page? There are some systems on which a key can be presses and the mouse
would then scroll the current window so long as you hold that key down.
Let's also not forget that if people click on radio button or
checkbox labels, they cannot move the window. Would THAT not confuse
users? You click on text, drag, and all it does it stay there, plus
change the current focus.
As for the other way around, if the person is used to the label
passing focus, they will simply choose non-text neutral space to move
the window.
> <http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2004-July/
> 001445.html> ("By breaking people's...")
The entire "mental model" argument seems to be predicated on the
idea that people will get confused about how the user can send
pointless, useless input to the computer and still have it ignored. It
also assumes that people who see text behaving like a radio button label
won't treat it as behaving similar.
>> 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.
Well, the IE "Address" label is greyed out, and Mozilla 1.7 and
Opera 7.5 don't have address bar labels, but I think I have a solution
anyway. If the <input> element is the only one in the <form> element, or
if there is no submit button, then Enter will submit the form.
Otherwise, Enter does nothing.
>> 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>
So, generally, you're saying that the spec doesn't define how
"Enter" is handled, and the the UA is responsible for making sure that
there are no problems arising from the use of the Enter key and the
function of <label>. How about having the spec state the circumstances
when the control can submit them form rather than how submission for
that control takes place.
>>>> 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.
From the specification:
"The LABEL element is used to specify labels for controls that do
not have implicit labels"
...AND...
"Each LABEL element is associated with exactly one form control."
Therefore, the use of "<label>Flavor:</label>" violates the
specification, since it is not associated with one form control, and the
whole point of <label> is to specify labels FOR CONTROLS.
> The rest of the
> code is valid, but I make no guarantee that it is conformant.)
I'm not sure what you mean by the terms "valid" and "conformant".
Unfortunately, the W3C does not provide a definition of the terms in the
context you're using them. (In fact, my spell checker and Dictionary.com
both fail to recognize the word, strangely enough.)
It should be pointed out that the user could implement the
functionality of a <label> element using Javascript and a <span>
element, or using <a href> on the label text. Nothing stops the user
from implementing the UI in a way that is inconsistent with operating
system conventions, including breaking conventions with regard to space
between controls. So you can't really prevent UI that is inconsistent
with the OS unless you disable large portions of Javascript and CSS.
On the other hand, you can easily make <label> behave like it does
in most operating systems by simply using text instead of the <label>
element. Why try to eliminate a feature of HTML when the web authors are
fully capable of dealing with and problems by making trivial changes to
markup?
>>> (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.
From what you quoted, I then have no clue what you're talking about.
Rather than be sarcastic about the "content model" of the <fieldset>,
why don't you just try explaining it again.
>>> 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.
So, generally, what you're saying is that UAs shouldn't be able to
add any functionality to existing controls that doesn't already exist in
the OS and that we should automatically change the HTML 4.01 spec to
require such changes, but you don't want to offer any proof as to why,
and you can't even come up with a webpage speaking against it. It would
seem I've put forth more effort to prove the necessity of changing the
<label> portion of the HTML spec than you have.
Received on Monday, 2 August 2004 19:18:59 UTC