Re: [w3c/uievents] Bug in spec? event.key and casing (#169)

I strongly believe that this is an issue of macOS.

If a modifier causes another letter, e.g., command key of Dvorak-QWERTY command keyboard layout, KeyboardEvent.key should represent the character coming from native key event.  Therefore, if Shift key changes the case of character, native key event of macOS should report the shifted character even when command key is pressed like other platforms.

So, I don't think that the spec is buggy.

When we discussed the .key value of printable key with modifiers, we decided .key value should be set from native key event if it's a printable character.  Otherwise, e.g., one of ASCII control characters, .key should be computed without some modifiers which caused non-printable char event.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/issues/169#issuecomment-343884048

Received on Monday, 13 November 2017 10:56:34 UTC