W3C home > Mailing lists > Public > www-dom@w3.org > January to March 2013

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

From: Wez <wez@chromium.org>
Date: Mon, 11 Mar 2013 14:57:39 -0700
Message-ID: <CALekkJe+L_Mgr7r3UZQUHDTZoVARPUQx5FHsCxPr=wH7ZRm6qw@mail.gmail.com>
To: Florian Bösch <pyalot@gmail.com>
Cc: "Hallvord R. M. Steen" <hallvord@opera.com>, Masayuki Nakano <masayuki@d-toybox.com>, "www-dom@w3.org" <www-dom@w3.org>
Yes, I completely agree!

On 11 March 2013 14:48, Florian Bösch <pyalot@gmail.com> wrote:

> 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.
Received on Monday, 11 March 2013 23:08:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:20 UTC