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

@garykac Thanks very much! I wasn't aware of the Keyboard Map proposal.

I've just given it a read, along with the original proposal/explainer, and it would indeed solve the problem for our use case — assuming that the privacy repercussions don't render the API unusable. I'm concerned that, if browsers require a permission prompt (as mentioned in [Privacy Mitigations](https://wicg.github.io/keyboard-map/#privacy-mitigations)), this would be out of context, overly confusing and annoying.

Our app, a music notation editor, displays the default keyboard shortcuts directly in context, in tooltips for each of the dozens of UI buttons:

<img width="226" alt="Screenshot" src="https://user-images.githubusercontent.com/180401/56520224-356c9200-6544-11e9-99cb-a784b7c84e61.png">

As it stands, I guess we'd need to show the permission prompt at the time of page load, which would be confusing because it wouldn't be directly tied to an obvious keyboard-shortcut user action.

Granted, this is a theoretical argument, because the spec leaves the permission-prompt question to browser implementations. But couldn't we sidestep that problem entirely if we provided the data in the `KeyboardEvent` itself, reducing the fingerprinting/privacy risk? As the proposal says, "similar fingerprinting can still be attempted, but it is more difficult since it would require the user to interact with the page by typing characters and analyze the resulting KeyboardEvents."

-- 
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#issuecomment-485527715