[PATCH] Automatic assignment of accesskeys

Tobias Anton tobias.anton at esc-electronics.de
Fri Apr 8 23:22:02 BST 2005


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.

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?

Cheers
-- Tobias




More information about the kfm-devel mailing list