I read about
KeyboardEvent.prototype.key and somewhere it was mentioned that one of its use cases is to let a developer provide a consistent keyboard experience, for example, in games, where the W, A, S, D and X keys are used for moving and similar, regardless of the keyboard layout of the user.
This is a good use case, however, applications (or even for help pages of games) that provide keyboard shortcuts (for example, the Developer Tools, GMail and others), cannot show meaningful keys to the user in some keyboard shortcut legend, because they cannot know in advance what
KeyA really is in the keyboard of the user. This creates some funny situations where the application shows that Control + A is the keyboard shortcut for selecting all of the characters, but since it relies on
KeyA, the shortcut will simply be wrong for German users with AZERTY keyboards, for example. It will do nothing, or worse - do something else (like discarding a new e-mail!).
My suggestion is to add a static method to
getCharacterByKey (bikeshedding for the name or the placement is welcome only after establishing that the concept itself seems like a good idea, obviously :)).
It will take two parameters,
key, which is the value of
KeyboardEvent.prototype.key, as well as a modifier list, which can be the same input used for
KeyboardEvent.prototype.getModifierState. The method will return the value of
KeyboardEvent.prototype.code (for the combination of the key and modifiers).
Privacy concerns - web applications will be able to identify the current keyboard layout (the operating system provided one, not the physical one, though) of the keyboard of the user. This can be used for fingerprinting in a way, though I heard that the number of bits that can be used for fingerprinting has already increased far enough for fingerprinting to happen anyway and thus fighting this specific concern is is pretty meaningless at this point. Also, it does not expose the name of the keyboard layout of the user, which can reveal much more about the locality, nationality or religion than just getting the keys.
Open questions -
- In case the user has two keyboard layouts (I have Hebrew and English, for example), which one will be returned? The current one at the time of calling the API?
- Should the method return a promise since it might involve some system calls?
- Should the method accept multiple combinations (use case - a keyboard shortcut legend usually includes more than a few shortcuts. This can make the application call this API a lot at once. This is especially useful in the promise-returning method case).
- Should the method return multiple outputs, per keyboard layout (in my case, one for Hebrew and one for English)?