Re: Keyboard events for accessible RIAs and Games

On Wed, Jan 30, 2013 at 9:31 AM, Florian Bösch <pyalot@gmail.com> wrote:

> To the first comment: The persistent description might not offer a user
> something he recognizes. This becomes relevant in the case I'm arguing for
> when a Web-Developer wants to construct a mapping dialog (example
> screenshot
> http://codeflow.org/entries/2013/jan/30/keyboard-events-in-javascript-are-broken/blender.png
> ).
>
> So for instance the (slightly contrieved) combination ctrl+shift+/+1 would
> read as: CtrlKey+ShiftKey+ForwardSlash+Digit1
>
> A possible translation to a users locale primary unmodified symbol for a
> printable key is still something that is desired (and is practised by any
> shortcut mapping dialog in existence).
>

Yes, trying to match the current (virtual) keycap was not a direct goal,
but adding the 'code' attribute makes it possible (when combined with the
current layout) to calculate a keycap value.

But I don't believe that this info belongs directly in the key event:
* We already have 2 (or 3) key attributes that encode the key information
and this would require adding one more. Adding yet another would make the
key events even more confusing to users.
* This functionality is useful outside of key events. For the key pref
dialog example that you gave, I assume that I'd have the 'code' (saved in a
pref file or something) and I'd combine it with the current layout to get a
value to display in the dialog. This would work even if the user changed
keyboard layouts.

So I definitely think we should provide the ability to get the keycap from
the key event, but I think a general API is preferable to encoding it in
the key event.


> The second comment: It is often desirable to have a numeric identifier (as
> well as a string) in certain combinations of resolving events to actions. A
> string necessitates usage of an object whereas a numeric identifier can be
> mapped trough an array. The latter is often preferred due to JS not having
> true hashes, and it might offer faster lookup (which while not particularly
> relevant in realtime, may become very relevant at event replays).
>

We initially proposed numeric identifiers (seeded with USB usage codes to
start), but got feedback that in the Web Platform constants should be
string rather than ints. Using strings also makes the code self-documenting
(compare "if (key.code == 49)..." with "if (key.code == 'Digit1')...").

Javascript performance is really a separate issue from this spec. Given the
tradeoff between code-readability and possible performance issues, I will
generally prefer code readability. In this case, even if I saw measured
performance issues with current JS implementation, I would still probably
opt for readability because I expect that JS perf (in all browsers) will
increase faster than this spec will be updated.

-Gary