Re: Event.key complaints?

On Thu 1 Nov 2012, Hallvord R. M. Steen wrote:
> I would like the "story" of event.char and event.key to be that
> event.char describes the generated character (if any) in its
> shifted/unshifted/modified/localized glory while event.key describes
> the key (perhaps on a best-effort basis, but in a way that is at least
> as stable and usable as event.keyCode).

I think we're mostly in agreement here (except for being satisfied with
"best-effort" key codes ^_^).

> Hence, what I think would be most usable in the real world would be
> making event.key a mapping back to un-shifted character values of a
> normal QUERTY (en-US) layout. Authors are asking for stable reference
> values for identifying keys, and that's the most stable and widely
> known reference keyboard layout.

The main problem with using unmodified 'en-US' values is that it doesn't
define values for keys that are not found on US keyboards. So, it's great
for US keys, but completely ignores the rest of the world. And once you
start looking at adding support for these other keys, you find that things
aren't so simple.

This is why we proposed using the USB codes - it defines unique values that
cover pretty much every modern keyboard that's in use.

Consider the following problems with using 'en-US':
* What should the 'key' value be for the "B00" key (located next to the
left shift - see the ISO/IEC9995-2 spec[1])? This is used in UK, Italian,
Spanish, French, German and many other keyboards.
* What should the 'key' value be for "B11" key (next to the right shift)?
This is used on Brazilian and Japanese keyboards.
* And "C12" (tucked under Enter key when Enter takes 2 rows)? Keyboards
with B00 usually have C12 as well.
* And "E13" (between += and Backspace)? Found on Japanese (Yen key) and
Russian keyboards.
None of these keys exist on a US keyboard.

The USB codes solve all of these problems because they've already thought
about all the keyboard variation that exists in the world:
* For B00, the USB code = 0x64, name = "Non-US \ and |".
* For B11, the USB code = 0x87, name = "International1".
* For C12, the USB code = 0x32, name = "Non-US # and ~".
* For E13, the USB code = 0x89, name = "International3".

Simply specifying the 'key' codes as coming from the 'en-US' layout leaves
too many details undefined and (while it may be marginally better than the
legacy keyCode values) will most likely result in a lot of browser
variation for these non-US "edge cases".

Because of these problems, specifying this field as containing unmodified
'en-US' key is not an adequate solution.

As for the solution we need to come up with, it doesn't matter to me
if it's:
* encoded in the current 'key' field, or in a new field (although it'd be
nice to have the 'key' field "do the right thing").
* a numeric value or a string (although I think a numeric value is
preferable to avoid confusion with the 'char' value).
* the exact USB codes or something similar that we derive from them.

But, we do need it to:
* be able to uniquely identify each key on the keyboard.
* be useful for all keys on all keyboards (and not just those that map
nicely to 'en-US')
* be straightforward to implement on all platforms.

-Gary

[1] See http://en.wikipedia.org/wiki/ISO/IEC_9995