Re: Way forward and IME behavior speccing

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.

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

Take the situation now, and lets say I wanted to create an academic editor
such as Fidus Writer under profit maximizing conditions:

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.

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

> /koji