Re: Way forward and IME behavior speccing

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.

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

/koji