[whatwg] accesskey attribute with display:none elements

[Calogero Alex Baldacchino]

Olli Pettay ha scritto:
> On 11/26/2008 02:34 AM, Calogero Alex Baldacchino wrote:
>> A
>> better way to do what you aim would consist of setting a listener for
>> key events on a displayable element and choosing a different operation
>> basing on the pressed key(s);
> This is not content author friendly way to do it, because different 
> browsers/OSes
> use different keys to activate accesskey targets.
> 
> -Olli

On one hand, whoever wished to write a 'complex' web application, with 
keybord shortcuts, should be aware of this concern and try and deal with 
it, since it's even more complex than you wrote, and might affect 
accesskey attributes too. The problem is, keybord shortcuts have always 
been strongly platform-dependent, while the web is aimed as a somewhat 
cross-platform architecture, so both accesskeys and key events handling 
cannot be 'fully author friendly'. I mean, a somewhat browser, on a 
somewhat OS, might use the same combination of modifiers (i.e. crtl+alt 
- just an example, not thinking on a real situation) to activate both 
its own controls (which take precedence) and a web page controls, so 
there is always a chance to choose an accesskey which won't work on a 
particular platform. Perhaps it was an heavier concern a few (or even 
several) years ago, since nowaday I think most browsers take great care 
on this matter, however such problem might arise from time to time, i.e. 
with a new browser version, or a version supporting a new OS (or a new 
OS version), or using an old browser version apparently compatible with 
a new OS version (but such should be a concern more for browser/os 
developers than for web developers, since the latter can only assume the 
underlying platform - browser + os - works correctly, and cannot care 
about any 'bug' outside their work, yet access keys, whatever way 
handled, cannot be though as a 'fully and always' reliable mechanism, 
while mouse clicks and tab-key navigation plus return-key activation 
usually are). Perhaps, keybord shortcuts may work better in a 'make 
application state'.

I agree that setting an accesskey attribute is easyer to deal with than 
handling key events, and the 'no-dimension, display:inline elements 
trick' stands always out there; anyway I think key events handling may 
be improved and become easier to adopt by adding to a somewhat interface 
a few constants representing the modifiers combination used by the 
browser to activate access keys, so those modifiers could be compared to 
the modifiers 'carried on' by the key event (this would require support 
for the DOM 3 Events, which I think could be improved/modified too -- if 
something like the above is yet present in html5 spec and I've missed 
it, I apologize).

On the other hand, the key events listener could just operate on single 
alphanumerical characters, something like (javascript-style)

switch(pressedKey){
	case 'a' : doSomething(); return;
	case 'b' : doSomethingElse(); return;
}

so to bypass any modifiers concern, with some extra care to avoid 
interferences with textual fields (and to avoid casual key pressing by 
the user - i.e. the very first time a key listened for is pressed, the 
webapp could just show an advise and list all valid shortcuts). Anyway, 
even in this case there would be chances to clash with a browser default 
behaviour for some keys (i.e. when the key is a digit).
 
 
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f
 
 Sponsor:
 Scopri i games più scaricati su cellulare! Gioca la tua partita!
 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=8272&d=26-11