#88558 - labels being focusable

Fri Oct 22 10:52:19 BST 2004

On Friday 22 of October 2004 02:55, Tobias Anton wrote:
> On Mittwoch, 20. Oktober 2004 14:41, Lubos Lunak wrote:
> > > In which spec did you read that?
> >
> >  In the spec called "My user experience says it is that way everywhere".
>
> That's exactly what I did _not_ ask for.

 Sorry, but that's the spec that usually counts the most.

>
> > In which spec have you read that labels should be Tab focusable?
>
> In the html spec, which you're obviously unaware of.

 And which you don't feel bothered enough to quote and or at least link to.

> >  Moreover, you commented on my reasoning with "That's your opinion. I
> > think differently."
>
> Your reasoning wasn't based on facts but on your bias. That's why I
> recognize it as an opinion.

 "2. labels are not focusable in others browsers"
 "3. labels are not focusable in other forms of GUI (Qt,...)"
 ...

> > > But be aware that the spec is not very precise on the focusability of
> > > labels. If there are doubts about how to read the spec, we can discuss
> > > it here. But please stop explaining the situation to me - it's
> > > understood.
> >
> > 1. the spec is not precise on the focusability of labels
>
> Did you read it?

 "But be aware that the spec is not very precise on the focusability of 
labels" - in case you don't recognize this anymore, look a couple of lines 
above (yes, exactly there where I quoted your mail).

 http://www.w3.org/TR/REC-html40/interact/forms.html#edef-LABEL :

 "When a LABEL element receives focus, it passes the focus on to its 
associated control."

 That's the only thing said about focus, it doesn't say anything about ways of 
receiving it or similar. If this is not the right spec or it's stated 
elsewhere, then please be so kind and spend a couple of seconds on saving me 
a lot of searching.

>
> > 4. labels in almost all cases directly precede their matching UI element
> > in the tab order (and the rest can be probably considered broken UI)
>
> This is a false assumption and will remain so even if you repeat that a
> million times.

 While your opposite assumption is true, even though you haven't provided a 
single proof for it, although explicitly asked?

 Ok, let's make this simple:

a) the element is right after the label in focus tab - just not having the 
label in tab order will in practice be the same like the label receiving the 
focus and forwarding it to the element

b) the label is not right before the matching element; for the lack of real 
world example let's consider this:
<html>
<body>
<label for="zelva">label</label>
<br>
<a href="/">kuku</a>
<br>
<a href="/tmp/" id="zelva">zelva</a>
<br>
</body>
</html>

 Tested with Mozilla-1.7.2, it acts like the label is not tab focusable. The 
same with Links and Lynx.

 Obviously, if the <label> was focusable, forward tabbing would never allow 
focusing of the first 'kuku' link, because Tab from the second link would go 
to the label, and the label should go back to the second link.

 Moreover, your implementation is against the spec. It doesn't forward the 
focus, as requested in the spec and quoted by me above.

 The conclusion for b) is that your implementation either breaks the spec, or 
it breaks the tab order.

>
> >  Reverting the patch is _the_ solution.
>
> No. What you probably mean is changing the return value of
> HTMLLabelElementImpl::isSelectable(). But I think we should do this
> intelligently - e.g. we could return true if the label has no "for"
> attribute or its ui element is not inside the label itself. The spec
> disallows nested focusable elements anyway.

 The code has been already altered by you, so the patch cannot be simply 
reverted. And the first patch snipped related to accesskeys is right. But 
since the rest of the patch doesn't make sense with isSelectable() returning 
false, the rest can be reverted as far as I can say, see attachment.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak at suse.cz , l.lunak at kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: khtml.patch
Type: text/x-diff
Size: 2029 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20041022/79409f4f/attachment.patch>