[w3c/uievents] Proposal: Add KeyboardEvent.unmodifiedKey (#229)

A web app I work on, [Soundslice](https://www.soundslice.com/), lets people add custom keyboard shortcuts. The shortcut-customization UI uses `KeyboardEvent.key` to display which key combination you've entered, and it uses the value of `KeyboardEvent.key` internally to save the user's custom shortcuts. [More info on the specific product feature is here](https://www.soundslice.com/blog/100/new-customize-your-keyboard-shortcuts/).

This generally works OK, but we have a problem with modifier keys. If you try to enter `Option g` as a shortcut (i.e., the `Option` key plus the `g` key), `KeyboardEvent.key` returns the copyright symbol "©" (on my particular keyboard locale). That's because `KeyboardEvent.key` returns the _string that would result from your keypress_ according to the modifier keys and keyboard locale.

I understand the reasoning for this, and in fact it's the whole point of `KeyboardEvent.key` as opposed to `KeyboardEvent.code` — but neither `key` nor `code` nicely handle this particular use case of custom keyboard shortcuts. A person creating a keyboard shortcut is thinking about the literal keys — `Option G` in this case — not the resulting character string.

At first glance, that suggests we should be using `KeyboardEvent.code`. The problem there is: we _also_ want the keyboard layout to be honored. On an AZERTY keyboard, hitting the "A" key sets `KeyboardEvent.code` to `KeyQ` and `KeyboardEvent.key` to `a` — the latter is what we want.

In short, I believe this use case would be handled elegantly if `KeyboardEvent` had an `unmodifiedKey` attribute. This would be the same value as `KeyboardEvent.key` (i.e., taking keyboard locale into account), but _without_ taking any modifier keys into account. This gives us the best of both worlds — the keyboard locale handling from `KeyboardEvent.key` and the physical-key-centric approach of `KeyboardEvent.code`.

If there's an existing way to accomplish this, I'd of course love to hear it! Thanks for reading. :)

-- 
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/229