Re: Way forward and IME behavior speccing

> On Oct 14, 2015, at 9:24 PM, Johannes Wilm <johanneswilm@gmail.com> wrote:
> 
> 
> On 14 Oct 2015 11:51 am, "Koji Ishii" <kojiishi@gmail.com> wrote:
> >
> > On Wed, Oct 14, 2015 at 6:20 PM, Johannes Wilm <johannes@fiduswriter.org> wrote:
> >>
> >> >
> >> > > > B) We make all of these IME-introduced changes preventDefault'able. IMEs will just have to be able to handle this if they want to be standards compliant. Also, may not a lot of this be doable creatively in the glue-code? If the IME doesn't allow preventDefault, but the default action is canceled in JS, couldn't the glue code simply abort the current IME operation (tell the IME that composition has been finished) and then start it again immediately thereafter and starting out with the text as it is after the JS defined operation. To the JS code that would make it look as if IME input would be preventDefaultable.
> >> > >
> >> > > This is probably possible because browsers do have the capability to cancel the current composition as needed on both Mac and Windows (and likely Linux).
> >> >
> >> > I don't agree with this. All IME actions being cancelable means almost the same as A to me. It's quite possible to create a situation like this editor doesn't work for Japanese, that editor not for India, and many editors do not work on Android because they cancel reconversion request.
> >> >
> >>
> >> Yes, it is certainly possible to program an editor so it doesn't work on Android, etc. . But that will always be the case. If you add more difficulties to JS editor developers they will just do as now and concentrate all their efforts on the most basic stuff with keyboard input and just leave out IME input, vertical writing mode, etc. entirely.
> >>
> >> The other option is that the browser makers add perfect editor components to their browsers, each hirering dedicated fulltime richtext editor development teams with the resources to give the level of customer support and quick fixes to bugs that projects such as CKeditor, TinyMCE, Aloha Editor, ProseMirror, Fidus Writer, Codemirror, Wikimedia editor, substance.io, etc. .that does not seem realistic in the near future, so we need to work here on giving the developers of such projects the power to solve the problems.
> >
> > That's exactly what I'm wondering.
> >
> > So today, users enjoy all the IME features, but due to that, they see issues in editors.
> >
> > With your proposal, we fix issues in the editors in the cost of disabling some IME features.
> >
> 
> 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).

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.

> I notice IME input seems to have "a life of it's own" and because of that the complexity of my app grows manyfold. So I ask my Chinese and Japanese friends how important it is for them. They tell me that good scientific articles of middle class and richer students will be written in English anyway. Then I notice that on Android everything is IME. But I also see that except in Subsaharan Africa, Windows 7 is much more used than Android. And also in Subsaharan Africa those with enough cash to be interesting as a market for my company write almost all academic texts on Windows. So my business decision is: forget IME, we are too small to support that.
> 
> The above is an exaggerated example, and I hope noone thinks like that. But people need to look at what their priorities are. And if IME input insists on imposing itself on everything else and it behaves in unpredictable and uncontrollable ways, chances are high editors will either disable it entirely or at least not support it in any meaningful way. You have noticed yourself how that is the case for several of the collaborative editor projects.

Again, IME WILL behave in unpredictable ways. We need to come up with an abstraction that hides such unpredictable behaviors from authors.

> > It'd be a hypothetic discussion that never ends. We can't promise B ends up with similar hindering to IME users as A, can we.
> >
> > Let's talk at TPAC. Maybe other Chrominians can agree, and I'm asking one of our colleague more familiar to IME APIs if he can join. IIRC some actions in IME are not really cancelable on some platforms, but I don't have all those details. The discussion is on Wednesday, right?
> >
> 
> Yes, Wednesday. Looking forward to meeting all of you there!

Yup, looking forward to talk about this in person.  It's really hard to talk about it on mailing lists.

- R. Niwa

Received on Tuesday, 20 October 2015 06:44:30 UTC