Re: Keyboard events for accessible RIAs and Games

Thanks for the link to the Event Level-4, it does indeed address some of
the issues of Event Level-3 (unmodified human readable persistent key
values). There are two comments I'd like to make based on my understanding
of Event Level-4 so far.

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

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).

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).

On Wed, Jan 30, 2013 at 6:10 PM, Gary Kacmarcik (Кошмарчик) <> wrote:

> This is not the first time these issues have been raised. The following
> threads can provide some context to the current state of the discussion:
> (obsolete
> proposal)
> Please also take a look at the UIEvents (formerly "DOM Level 4 Events")
> Editor's Draft at:
> I believe that it addresses all of your concerns but I'm interested in any
> comments that you might have.
> Thanks,
> -Gary
> On Wed, Jan 30, 2013 at 6:05 AM, Florian Bösch <> wrote:
>> I have written a blog post at length about this issue here:
>> In short the problem is the following:
>> - RIAs (shortcut systems) and Games (shortcut systems and action systems)
>> need to be able to identify each key uniquely regardless of modifier keys
>> pressed.
>> - To make things mappable an unmodified primary symbol or description
>> needs to be available to display to the user.
>> - To make things speedy to handle there should also be an accompanying
>> unmodified keyCode (numeric)
>> The current event model (keyCode, charCode and which) do not satisfy that
>> requirement:
>> - The same keyCode appears on multiple keys
>> - The same charCode appears (differently from keyCode) on multiple keys
>> - charCode and keyCode change based on modifiers
>> - keyCodes cannot be converted to a users locale
>> - no non printable key descriptions are offered
>> - "which" is a combination of all the problems above.
>> It is recognized that this is not a good way to do things as for instance
>> the MDN already lists "keyCode", "charCode" and "which" as deprecated.
>> The DOM Event Level 3 does not solve all these problems:
>> - The char member is still being delivered modified
>> - The key member has to match the char member for printable keys
>> - There is no numeric unmodified keyCode
>> I would suggest:
>> - Add a primary key symbol (printable, from the users locale) umodified
>> and for non printable keys add the human readable description ('backspace',
>> 'enter' etc.)
>> - Add an additional unmodified key code member holding the numeric key
>> code unmodified

Received on Wednesday, 30 January 2013 17:32:11 UTC