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

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.
>>>
>>
>>
>