Re: [D4E] KeyboardEvent.code and KeyboardEvent.queryKeyCap() are very strange spec

On Mon, Mar 11, 2013 at 4:33 AM, Masayuki Nakano <masayuki@d-toybox.com>wrote:

> My concern is, the code values don't indicate that they are named for
> en-US (QWERTY) keyboard layout. Therefore, I believe that a lot of web
> developers will misunderstand the meaning of code value.
>
> For example, when Japanese web developers try to handle Ctrl+':', they
> might (want to) compare with 'Colon' rather than 'Quote'. It feels very
> strange for me. Indeed, as you say, .key value should be ':'. However, at
> least in Japan, it's not intuitive behavior because most Japanese people
> don't familiar with en-US keyboard layout (especially, which punctuation
> key inputs which character). So, I don't feel en-US QWERTY layout is well
> known layout for the people all over the world.

The key.code parameter could as well just be an opaque number. I don't know
if it would be a problem that it'd look like keyCode, it is after all a
different attribute, and it behaves differently.


> Yeah, I realized that if we use unique numbers like keyCode, most web
> developers will probably compare the code value with fixed number. Then,
> such developer's web application won't work for unexpected keyboard layout.
> In Japan, most people don't familiar with en-US keyboard layout, however,
> actually, few people prefer en-US keyboard layout rather than JIS keyboard
> layout. So, it's possible to cause such inaccessible web application.
> However, I don't like the value name is based on en-US QWERTY layout...
> Hmm...

You will want people to compare the code directly, without a translation.
That is the only way to make shortcut systems configurable for a users
machine.


> Yeah, I agree with that. My main idea is, the .code value should not be
> referred by web developers directly. In the current draft, they should
> always use queryKeyCap().

Therefore, one of my suggestion is, .code property should be removed
> because in my understanding, the code value is useful only for an argument
> of queryKeyCap().

No, queryKeyCap is to *display* something to a user, such as a
configuration dialog, the code is what you react to, and store in your
configuration.

You do not seem to understand what shortcuts and configurations are. So
I'll explain it again, though I've done so there already:
http://codeflow.org/entries/2013/jan/30/keyboard-events-in-javascript-are-broken/

A shortcut is a combination of keys pressed, one or more, either
simultaneously or in sequence, that cause something to happen. This kind of
user interaction is found in all desktop applications (notepad, word,
games, browsers etc.) and some terminal applications (vim, emacs).

Shortcuts are usually made configurable for the user (see these examples
http://codeflow.org/entries/2013/jan/30/keyboard-events-in-javascript-are-broken/blender.png

http://codeflow.org/entries/2013/jan/30/keyboard-events-in-javascript-are-broken/gimp.png

http://codeflow.org/entries/2013/jan/30/keyboard-events-in-javascript-are-broken/minecraft.png)
by the application developer.

One (or more) default shortcut configurations are usually offered to users.

A shortcut configuration display needs to display the character appearing
on the users keyboard to describe a shortcut to the user, so the user can
tell if a shortcut is inconvenient for him and reconfigure it.

To meet all the above criteria the following straightforward capabilities
have to be provided:

- A key event triggered on key down and key up for each key
- A unique identifier for each key that should match position on the
keyboard across different keyboard layouts
- The unique identifier is always the same regardless of modifier state,
i.e. a key only ever issues one identifier
- One unique identifier is issued only by one key, and not any two or more
keys
- The unique identifier can be translated to a key cap to display to the
user inside a shortcut configuration screen

The benefit of doing this is that:

- Even if using a fixed key.code comparison (or a default layout), keyboard
controls will work for many users using many different keyboard layouts
- A meaningful configuration dialog can be presented to the user by the
developer.

The above is necessary because:

- keyCode is subject to modifier state, the same keyCode appears on
multiple keys, one key issues multiple keyCodes
- char/key/which/etc. is for character input which is both subject to
modifier keys as well as that it can't express non printable keys