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
