Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Expose keyboard language? #15

Open
alexkeng opened this issue Oct 7, 2021 · 6 comments
Open

Expose keyboard language? #15

alexkeng opened this issue Oct 7, 2021 · 6 comments
Labels
enhancement New feature or request

Comments

@alexkeng
Copy link
Contributor

alexkeng commented Oct 7, 2021

currently it appears keyboard language is not exposed to JS. Adding this to EditContext could help authors in some scenarios where IME info is needed.

@garykac
Copy link
Member

garykac commented Oct 7, 2021

Keyboard language / layout is explicitly not exposed to the web because of fingerprinting concerns. The current layout (or set of installed layouts) can be very discriminatory when trying to identify users based on their machine profile.

For this reason, I don't see it happening just because it "could" be useful in "some scenarios". If you have specific scenarios where this information is necessary, then that would be a better place to start this conversation.

Note that Keyboard Map is an example of a proposal that was created specifically to address a particular case where it was believed that the keyboard layout was needed to describe keyboard shortcuts.

@alexkeng
Copy link
Contributor Author

thanks for the comment, the scenario is the author wants to know which IME (ex. Japanese) is current in use, so they can load corresponding fonts in their app and render the typed text in a canvas element.

Could Keyboard Map help in this scenario?

@rniwa
Copy link

rniwa commented Oct 29, 2021

thanks for the comment, the scenario is the author wants to know which IME (ex. Japanese) is current in use, so they can load corresponding fonts in their app and render the typed text in a canvas element.

I don't think you can ever determine which fonts are needed before the text is actually typed. Japanese IME, for example, supports converting romaji as well as an arbitrary unicode character from a table of characters. Not only that, users can simply paste some content from another application. So the only reliable way to load fonts is to either load the most generic font or determine it once new characters are inserted into the document.

@alexkeng
Copy link
Contributor Author

alexkeng commented Nov 2, 2021

@rniwa thanks for the comment! it makes sense, I'll close the issue for now.

@alexkeng alexkeng closed this as completed Nov 2, 2021
@alexkeng alexkeng reopened this Feb 7, 2022
@alexkeng
Copy link
Contributor Author

alexkeng commented Feb 7, 2022

reopen to address concerns from Adobe

@macnmm
Copy link

macnmm commented Feb 7, 2022

In the missing font case, the incoming Unicodes can be ambiguous as to which language they correspond to, so in order to choose the correct fallback font you would have to know the current IME (keyboard) being used. Normally an incoming text stream is accompanied by the keyboard script information so font choice can be automated, and other script-specific settings like spell-checking or hyphenation or line breaking rules can be set automatically and not pollute the UX with complexity.

@travisleithead travisleithead transferred this issue from w3c/editing Apr 21, 2022
@dandclark dandclark added the enhancement New feature or request label Oct 26, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

6 participants