w3c / edit-context

EditContext API
https://w3c.github.io/edit-context/
Other
28 stars 7 forks source link

Expose keyboard language? #15

Open alexkeng opened 2 years ago

alexkeng commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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

alexkeng commented 2 years ago

reopen to address concerns from Adobe

macnmm commented 2 years ago

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.