RE: Re: Event.key complaints?

Awesome stuff Gary.

(And I like that we won't need to change the behavior of key or char in your proposal—that part made me really nervous, since IE has shipped this stuff since 9, and I know our new Win8 app model is using it.)

I'm planning in the short term to start a new DOM4 Events spec, which will be the successor to DOM3 Events. I brought this up at TPAC and there were no objections. Gary, I'd love you collaboration on specifying your new "code" property in that spec.

-Travis

From: garykac@google.com [mailto:garykac@google.com] On Behalf Of Gary Kacmarcik (?????????)
Sent: Friday, November 30, 2012 2:11 PM
To: Hallvord Reiar Michaelsen Steen; public-webapps@w3.org
Subject: 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