Re: exposing underlining mechanism for IME?

> On Nov 5, 2015, at 10:32 PM, Johannes Wilm <johannes@fiduswriter.org> wrote:
> 
> looking at some files around IME in blink's source code. The code for markers (spelling, composition) looks interesting. Are there security concerns that make us not expose those to JS? If so, what concerns are those?

Yes. Composition text are usually broken into chunks (usually words) using heuristics.  This heuristics in turn can expose privacy-sensitive information such as names they recognize, etc... because it depends on user dictionary.

> It seems like the main problem problem for IME is figuring out what is a candidate text (what is underlined), what is committed. Candidate text is already part of the DOM, so for us who look at the DOM from the perspective of JavaScript, it makes it all really difficult to deal with, and for those working in the browser world everything is getting more complex when we try to do anything unpredicted in JS because you then need to make sure that your underlining mechanism works correctly.
> 
> But what if we exposed something like 
> 
> addCompositionMarker(range,color,thickness,backgroundColor) 
> 
> where the color, thickness and backgroundColor are optional and if the user doesn't chose anything, the colors of the current IME will be used. 
> 
> That way one doesn't have to expose information about what colors and line thickness the current IME is using. But Google Docs, which apparently shows character creation to collaborators, can then use a different underline color for characters that a collaborator is currently composing.

We can't quite specify "thickness" since that's determined by the platform. Also, composition markers need to split the composed text into chunks so we still need to match the next in the range with what IME sees.

At that point, there is no reason to specify the range because the composed text should appear before the insertion point (collapsed selection) anyway.

> We could also have
> 
> addSpellingMarker(range,color)
> 
> where the color is optional. If not specified it's the default spelling color. Because many editors have to turn of the builtin spell checker (Word online is using contenteditable and turns of the spellchecker that, and CKeditor, TinyMCE, etc. do it as well), this would allow for the third party replacements that the editors use instead to be shown equally well.

If you're replacing the builtin spellchecker, just use text-decoration: wavy.

- R. Niwa

Received on Monday, 9 November 2015 22:15:52 UTC