Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Broaden the scope of the specification to support web IDEs #26
The current draft states the following non-goals:
I understand that for the currently described user scenario, keypress instructions in games, this is acceptable. There is another scenario that is unsufficiently supported by web APIs: command keybindings in web IDEs. In this other scenario, the three stated non-goals are exactly the missing piece that would allow to handle keybindings for IDE commands properly. This can be explained best with an example.
The Visual Studio Code keybinding for the command "Toggle Line Comment" is
VS Code is an Electron application and uses the native-keymap package to determine the keyboard layout (see microsoft/vscode#713). Since that is an OS-native library, it cannot be used in a web application.
If we would have a web API that allows us
a web IDE could identify the complete keyboard layout and thus adapt the configured keybindings to the user's keyboard. This is exactly the kind of information that is provided by the native-keymap package for VS Code.
The inverse mapping, that is the ability
would be useful, too, in that context, though it could also be derived from the mapping above and thus does not add any new information.
In case a web IDE would like to display the detected keyboard layout to the user,
would be necessary.
In summary, web IDEs need some means to query the mappings from
The current proposal of the Keyboard interface could be extended so the
As a committer of Eclipse Theia, my main motivation is to improve support for international keyboard layouts in that web IDE. Theia is currently used in
Of course other web IDEs could also greatly benefit from better keyboard layout support in the web API, for example
Web IDEs are emerging very quickly, which shows that there is a high demand for them. However, the web APIs are not prepared for this kind of user scenario when it comes to keyboard events.
The impact on users' privacy is basically the same as for the currently proposed API (see #8). Of course adding modifiers to the keyboard layout information increases the fingerprint in terms of the amount of data, but I assume it does not change much about the identifiability of a certain keyboard because most keyboards should be already fully identified by their character layout without modifiers. This assumption needs to be verified, though.
How to Proceed?
I am submitting this issue because the current keyboard-map proposal is already quite close to the needs of web IDEs. The missing piece are the modifier keys.
If you think what I describe would be better put into a separate draft, I'm fine with that. My intention is to start a discussion on this so eventually we can improve the user experience for web IDEs.