Bug in spec? event.key and casing

[keithamus]

I have filed https://bugs.webkit.org/show_bug.cgi?id=174782 due to a non-spec-conformancy issue in Safari about the value of event.key being lowercase when using a keyboard combo like cmd+shift+p. Safari developers have suggested this is an issue with the spec, not Safari.

Now it seems as though Chrome ~62 follows this same behaviour. Perhaps this should be considered normative? In any case there is a clear discrepancy between (now) 2 browsers and how they behave, and the UIEvents spec.

The parts of the spec in question are https://www.w3.org/TR/uievents/#keys-modifiers and https://www.w3.org/TR/uievents/#example-aa6d4cea

[masayuki-nakano]

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.

[marijnh]

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.

Why? It seems like web developers need portable behavior here. Not being able to figure out what a given key event refers to is a real problem. As a specific example, say you have an app that wants to bind Ctrl (or Cmd) + dollar sign to perform some currency-related action. You don't know the user's keymap, so you don't know whether a dollar sign involves shift or, if it does, which shift-less character it shares a key with. If you can't depend on key holding the appropriate printable character, I don't know of a reliable way to implement such a key binding.