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> 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> wrote:
>
>> On Mon, Mar 11, 2013 at 9:41 PM, Wez <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.
>>
>
>