- From: Matthew Raymond <mattraymond@earthlink.net>
- Date: Wed, 21 Jul 2004 14:50:58 -0400
Matthew Thomas wrote:
> On 21 Jul, 2004, at 1:58 AM, Mikko Rantalainen wrote:
>
>> ...
>> So, the *real* problem is that UA sends form on pseudo-random basis[1]
>> if user presses ENTER
>
> 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.
>> and to fix this, you think that label should be forbidden for other
>> controls but checkbox and radio button?
>
> 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. You also fail to
consider cases when the behavior is a non-conflicting superset of the
operating systems conventions.
>> How about fixing the ENTER key issue, instead?
>
> No, because in that detail UAs are already following native behavior of
> the Enter key.
>
>> I agree that having ENTER to submit the form is a great feature in
>> some cases -- for example, when I use Google, I love to be able to
>> just hit enter to submit the form after entering the query. However,
>> if the form contains more single line inputs, or heaven forbit, a
>> textarea or two, then it definately does NOT make any sense to submit
>> the form with ENTER key.
>
> 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.
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. Furthermore,
there are situations where you don't necessarily want there to be a
default button triggered by hitting enter.
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.
>> 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. In HTML, a <label> can be associated with
only one control, either by explicitly using the |for| attribute, or
implicit association by making a single <input> element a child of the
<label>. Having multiple controls as children of a single <label> is
invalid markup.
> (for which <fieldset> would usually be inappropriate).
Of course it's inappropriate, since <fieldset> uses <legend> for its
caption, not <label>.
>> I claim that best choice is to leave UA to decide which controls
>> should be focusable via label, though I still think that the correct
>> answer is that all elements are focusable via label.
>
> So lobby your OS vendor to change the OS behavior.
I'll ask Microsoft to do that right after I get them to decouple
Internet Explorer from the operating system and file system.
Note that Mozilla and Opera already have the label passing behavior.
IE has it for explicitly associated controls.
> 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. And yes, the
threshold is SIGNIFICANTLY inconvenienced, since you are the one
proposing the removal of behavior from the specification. I propose only
a clarification of the HTML spec related to how labels handle mouse clicks.
Received on Wednesday, 21 July 2004 11:50:58 UTC