Re: Way forward and IME behavior speccing

On Tue, Oct 20, 2015 at 8:28 AM, Ryosuke Niwa <rniwa@apple.com> wrote:

>
> > On Oct 14, 2015, at 9:24 PM, Johannes Wilm <johanneswilm@gmail.com>
> wrote:
> >
>
...

> >
> > This is only one of the options, if we cannot get any better controls on
> IME. If we can get preventDefault, if we can influence what the IME
> considers a word when moving text back into the IME for editing, if we can
> sandbox it and only get an atomic commit, then we don't need that.
>
> I think that would be hard because a part of IME's job is to figuring out
> where word boundaries occur. In both Chinese and Japanese, word boundaries
> can never be precisely determined because they're context sensitive (e.g.
> there is no dedicated character or a sequence of characters that denote
> start or end of a word).


Right. but JS may know something more about certain DOM element boundaries
which won't let words cross them. That's why in an ideal version I would
like to be able to influence the idea the IME had about word boundaries.
And I think that should be possible without destroying anything for
Chinese/Japanese: IME says where it thinks the word is, and JS has an
opportunity to to change that (but doesn't have to).

But in the latest few emails, I was actually asking for even less for this
first version. Instead of letting us influence where those word boundaries
occur, let us at least know where these word boundaries are in the DOM once
you have found them (in the form of a range). Right now we already get the
contents of the word that was found as the data attribute of the
compositionstart event. And we know where the caret is. So it is possible
to find out what rnage that corresponds to, but it's quite a lot of work.
Consider this case:

<p>This is a sentence with <b>a part</b>ia|l<i>ly styl</i>ed word.</p>

| = caret

Now composition starts on Android/iOS and the compositionstart event's data
attribute is "partially". Yes, we can probably figure out what range that
corresponds to already now in JavaScript by going back and forth in the DOM
until we have found enough letters in text nodes that correspond to the
given word, but it would be much simpler if the browser would just directly
hand that information to us.


>
> The idea of restricting the user-perceived IME behavior is going to be
> very controversial, and it's NOT something we (Apple) would like to support
> as a part of new editing API.
>
> > > It's clearly a plus, without any minus, for non-IME users. But for IME
> users, is it really a plus? That'd be a hard comparison, we need to know
> what issues JS can't work out today, and we need to know what IME features
> JS wants to disable.
> >
> > I think it will be a plus even if only limited features are available,
> but I am all for more advanced features if we can preventDefault and get
> them to behave predictably.
>
> I don't think disabling any IME feature is acceptable.  Again, IME
> behaving differently in Web apps and native apps is going to provide a
> horrible experience for end users.
>

Right, I think if we can agree on JS being allowed to sandbox IME, the way
we had talked about at the last F2F, then most of these issues will not be
as important.

So once again: all these other proposals are only strictly necessary at
this stage if we cannot get to sandbox IMEs both in composition and in
recomposition mode. If we can sandbox, most/all problems will be restricted
to things on potentially looking visually weird during composition itself.



-- 
Johannes Wilm
http://www.johanneswilm.org