Re: exposing underlining mechanism for IME?

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?


>
> > 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.


> 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.


>
> > 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.


>
> - R. Niwa
>
>


-- 
Johannes Wilm
Fidus Writer
http://www.fiduswriter.org