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

1.      Just because a UA incorrectly implements the keydown/keyup event doesn't mean a new spec will fix the problem. Bugs in UA implementations of keydown/keyup and standardization of charCode can be fixed to the extent that it is fixable. Part of the problem is the hardware dependent nature of it, and have existed since DOM 0.

2.      Usually there is no standard way for an app or browser to answer the question "given a text character, what key or sequence of keys will generate [this] character?" since it is a question the driver answers.

3.      On a given OS, applications (the UA is also an application) generally receive their events in a form that has already received some processing from the system, such as to take advantage of system extensions or IME.

http://www.quirksmode.org/js/keys.html gives a good description of the situation as you describe it, particularly with regard to charCode and keyCode.

From: Florian Bösch [mailto:pyalot@gmail.com]
Sent: Monday, March 11, 2013 2:48 PM
To: Wez
Cc: Hallvord R. M. Steen; Masayuki Nakano; www-dom@w3.org
Subject: Re: [D4E] KeyboardEvent.code and KeyboardEvent.queryKeyCap() are very strange spec

Point is, keyCode behaves in ways less than useful on top of not being useful at all to display a shortcut dialog because the keyCodes can't be translated to a key cap for a users keyboard layout. From where I'm sitting, on any of my three OSes/Machines, and from any of a potential userbase, keyCode is an utter clusterfuck. It doesn't transport between platforms, it doesn't transport between browsers, it isn't consistent, it isn't sufficiently unique, it's issued from multiple keys, and same codes come from the same keys, some keys are treated differently than others, and so on. It is completely, utterly useless to build a reliable keyboard shortcut system. Any futile attempt to do that will result in no end to users moaning to about how your application is broken. And no amount of dancing around the various idioscyncracies can fix it because whenever you fix it for one user, you break for another. That is what event.code and queryKeyCap should (presumably) fix.

On Mon, Mar 11, 2013 at 10:34 PM, Wez <wez@chromium.org<mailto:wez@chromium.org>> wrote:
My comments re keyCode are based on the prevalent Windows virtual key code scheme - from what you've described it sounds like you're testing on a browser that uses that scheme, but on a non-Windows platform for which it has a buggy implementation of keyCode.

On a Windows system Chrome/WebKit will produce:
- keyCode=49 for both 1 and Shift+1.
- NumPad keys actually do change according to shift state (at the PS/2 level NumLock is actually implemented as a virtual shift state), but Shift+0 should not produce keyCode=0.
- left & right keys (shift, ctrl, alt) have the same keyCode because Windows reflects the underlying PS/2 codes, which distinguish them by setting the "extended" bit for the right one, and not setting it for the left.
- The backtick behaviour is because it's a dead key in your selected language layout. The browser should arguably treat that as a special-case IME, deliver keydown/keyup for the key as normal and provide composition events for the resulting text.
- Again, the difference between $ unmodified and shifted sounds like a bug in the browser's emulation of Windows virtual keys for your platform. :(


On 11 March 2013 14:00, Florian Bösch <pyalot@gmail.com<mailto:pyalot@gmail.com>> wrote:
On Mon, Mar 11, 2013 at 9:41 PM, Wez <wez@chromium.org<mailto:wez@chromium.org>> wrote:
Which keys are you thinking of?  keyCode changes for some keys based on lock-states (the NumPad keys) but not for shift/ctrl/alt modifier-states.

- the key "1" (above the alphabet) has the keyCode 49, but when I press shift+"1" it becomes 187.
- the key "0" (numpad) has the keyCode 96, but when I press shift+"0" it becomes 0
- left/right shift both have the same keyCode (16)
- left/right ctrl have the same keyCode (17)
- main block and numpad "enter" have the same keyCode (13)
- The backtick key does not trigger a keydown event (`/^), only on the second press it does.
- The $ key is 52 unmodified, but 220 with shift
- etc. etc.