Re: Re: Event.key complaints?

On Thu, Nov 8, 2012 at 6:37 AM, Hallvord Reiar Michaelsen Steen wrote:

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

Gary responded:

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

Hallvord replied:

> Yep, and the solution to that is listing those keys and figuring out what
> their preferred key name should be. [...]
>
> Thanks for coming up with your list :-)

That wasn't really supposed to be a list, just a few obvious problematic
examples. ^_^

However, I've spent some time over the past few weeks working to identify
all the problem cases so that we can have a more concrete proposal.

But first (for background), I extended your key event "stories" into 3
basic scenarios that I refer to (for lack of better, unambiguous terms) as
CHAR, MEANING and CODE.


CHAR (high-level character info)
--------------------------------
The CHAR use-case is for users who are interested only in the printable
final character that the user typed (or entered through some other means).
The user gets the char info by handling 'keypress' (deprecated) or HTML5
'input' events and reading the 'char' field from the KeyboardEvent.
Example use-case: Detect character input (to validate field after each char
is entered)

MEANING (high-level key info - virtual key meaning)
---------------------------------------------------
The MEANING use-case is for users who are interested in the meaning of the
key being pressed, taking into account the current keyboard layout (and IME
and dead keys).
Example use-case: Detect modified keys or bare modifier keys (to perform an
action in response to shortcut)

CODE (low-level key info - physical keys)
-----------------------------------------
The CODE use-case is for users who are interested in the key that was
pressed by the user, without any layout modifications applied.
Example use-cases: Games (detect WASD keys for movement), Remote desktop
client (trap all keys to send to remote host)


I was hoping that the MEANING and CODE scenarios could be satisfied with a
single field in the KeyboardEvent structure, but further reflection has
convinced me that this is not possible.

Consider these examples that demonstrate the difference between MEANING and
CODE, and why both are needed:

Left/Right Alt key:
                    CHAR     MEANING       CODE        location
   US Keyboard       ""       "Alt"       "AltLeft"    left
   US Keyboard       ""       "Alt"       "AltRight"   right
   French Keyboard   ""       "Alt"       "AltLeft"    standard
   French Keyboard   ""      "AltGr"      "AltRight"   standard
   Notes:
      MEANING permits matching "Alt" regardless of which Alt key was
        pressed.
      CODE permits matching "AltRight" regardless of which layout is in
        effect.
      The location for "Alt" and "AltGr" is 'standard' since there's only
one
        of each key. Arguably, these values could be 'left'/'right' to match
        the US layout.

Single Quote key:
                    CHAR     MEANING       CODE
   US Keyboard       "'"       "'"        "Quote"
   Japanese Kbd      ":"       ":"        "Quote"
   US Intl Kbd       ""    "DeadAcute"    "Quote"
   Notes:
      For US Intl Kbd, we can't use the unmodified US key ("'") in the
        MEANING since that's where the dead key is specified.

Equal Sign (with Left Alt pressed):
                    CHAR     MEANING       CODE        modifiers
   US Keyboard       ""        "="        "EqualSign"  Alt
   Korean Kbd        ""    "JunjaMode"    "EqualSign"  Alt

Two (with Shift key pressed):
                    CHAR     MEANING       CODE
   US Keyboard       "@"      "@"         "Digit2"
   UK Keyboard       """      """         "Digit2"
   French Keyboard   "2"      "2"         "Digit2"
   Notes:
      If we adopted MEANING = unmodified US key, then the MEANINGs would
        all be "2" instead of varying. That would fix this case, but
        wouldn't help the other examples given here.


Note that neither the MEANING nor the CODE is sufficient by itself to
encode the info needed for all the desired use cases.

As for where to store this information, it's clear that we need 3 separate
fields. We already have 'char' and 'key' in the spec with 'char'
corresponding to CHAR and 'key' corresponding to MEANING. I propose a new
field 'code' which encodes the CODE information.

Note that, wherever possible, the CODE names come from the US keyboard
layout. So these values will be familiar to most developers while still
satisfying the requirement to provide for a unique mapping from code name
to physical key.


I'll be following up with a more complete description, but I wanted to put
this out there now for comments/feedback. I've started reviewing the
contents of the "6.2.7.1 Key Values List" and have a some
corrections/updates that I'll post separately.

>> 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.
>
>I don't think we can fulfil all three - particularly not the latter.
That's just the way it is :-(

I don't believe the situation is as dire as that. We already have a
prototype dev_ implementation that exposes USB scancodes to Chrome plugins
and it satisfies all three of these requirements (cross-platform, simple
lookup, and unique id for each key). Switching from USB scancodes to
DOM-friendly key names is trivial. We haven't exposed this information to
the DOM because we're hoping the standard will be able to support our use
case.

-Gary