[PATCH] Automatic assignment of accesskeys

[Lubos Lunak]

Dne so 9. dubna 2005 0:22 Tobias Anton napsal(a):
> Am Freitag, 8. April 2005 17:06 schrieb Lubos Lunak:
> > > Otherwise, the function
> > >  DOM::NodeImpl::isSelectable()
> > > might be useful to determine - in a generic way - whether an accesskey
> > > makes sense. This way, you could cope with selectable elements whose ID
> > > you don't know (may happen e.g. when rendering XML or perhaps in case
> > > of advanced CSS usage).
> >
> >  So the default case in the first "switch( element->id())" should be
> > changed from "ignore = true" to "ignore = !element->isSelectable()" ? I'm
> > not quite sure I understand what you mean, you shouldn't try to scare me
> > with talking about rendering XML or advanced CSS usage :).
>
> At first: s/isSelectable/isFocusable. Sorry, I had an outdated codebase in
> mind.
>
> AFAICS, your loop completely enumerates all html elements that are known to
> be selectable, but you can never know if it is really complete. Also,
> elements that are selectable normally can be disabled by means of CSS.
> Those elements shouldn't react on accesskeys, so they shouldn't be assigned
> automatic accesskeys either.
>
> The solution: All elements that can receive keyboard or mouse focus return
> true when
>  DOM::NodeImpl::isFocusable()
> is called. Disabled elements are supposed to return false.
>
> So, every element that isFocusable() also is a candidate for an accesskey
> and every one that is not can't be focused or activated anyway.
>
> The bottom line:
> I'd suggest removing this:
>             default:
>                     ignore = true;
>                     break;
>             }
>             if( ignore )
>                 continue;
> , adding a:
>  if (!element->isFocusable())
>   continue;
> before the switch(), and implementing a generic way for picking the
> accesskey for generic DOM elements in the
>  default:
> section of the switch-statement.

 If isFocusable() can change dynamically then I don't think it would be right 
to use it there - that'd mean the relatively random assignment of accesskeys 
could become even more random and changing. Adding it in the default switch 
case is fine but I'd rather have few accesskeys assigned to disabled controls 
than having one accesskey assigned to more elements of one form at different 
times.

>
> Picking the first unused non-whitespace character of the descendant::text()
> nodes seems appropriate.
>
> Note: This is only my HO. I still haven't understood what the
> fallbackAccessKeysPriorityWords() thingie is about. How does it work?

 It's a list of expressions that increase priority of various elements if they 
contain some of the texts (so that you can make e.g. 'Next' and 'Previous' 
always have an accesskey). But I've already changed my mind on this, I think 
it would be better to be able to specify 'N:Next in thread,P:Previous in 
thread' etc., so that one would be able to specify exact accesskey for some 
of the often used links and it would not change randomly as it does now (e.g. 
the already mentioned 'next in thread' at lists.kde.org). I wonder if that 
would be worth a GUI setting (probably not).

-- 
 Lubos Lunak
 KDE Developer