Re: exposing underlining mechanism for IME?

> On Nov 9, 2015, at 10:06 PM, Johannes Wilm <johannes@fiduswriter.org> wrote:
> 
> 
> 
> On Mon, Nov 9, 2015 at 11:15 PM, Ryosuke Niwa <rniwa@apple.com> wrote:
>> 
>> > 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.
> 
> I see. So the underlined part (the composition string), is further divided up into these chunks, and we cannot tell the JS what chunk is part of what? Is there a way for the end user to tell from looking at it how the different chunks are divided?

Yes, that's the whole point of breaking into chunks.

>> 
>> 
>> > 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.
>> 
> 
> Ok, I clearly need to understand those chunks better.

You can see an example at: http://www.w3.org/TR/ime-api/#selected-clause

> 
>> At that point, there is no reason to specify the range because the composed text should appear before the insertion point (collapsed selection) anyway.
> 
> yes, but then there are the cases that you mentioned yourself where one may want to put each letter inside its own span, etc. 

That's okay as long as those spans are appear in the right order in the DOM because then browser can get innerText throughout those elements.

>> 
>> > 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.
> 
> true. Only disadvantage is that one needs to put a span around the word. It seems that these markers can be put on just ranges including partial text nodes.

Such is a fundamental limitation of CSS.  I don't think we want to introduce a new mechanism to style text.

- R. Niwa

Received on Wednesday, 11 November 2015 01:20:00 UTC