Re: Way forward and IME behavior speccing

On Mon, Oct 12, 2015 at 2:52 AM, Ryosuke Niwa <rniwa@apple.com> wrote:

>
> > On Oct 11, 2015, at 11:29 AM, Johannes Wilm <johannes@fiduswriter.org>
> wrote:
> >
>
...

> > So, to stop all of this, we need a clear specification of IMEs. And it
> needs to be restrictive. There are a million things IMEs might do, but if
> every IME does it's own thing, it's bound to just break most of the
> internet and not to be of benefit to anyone.
>
> The problem is that we can't. IME is a system component. Browsers can't
> modify how IME works on each system.
>

Ok, that is an important point. But if this system component ends up
creating and manipulating DOM structures (not just editing text nodes),
then surely there must be some way to talk about/standardize the structure
of the added/edited nodes, right? Else, what is there to stop a specific
system from inserting something like  "<span style="font-size:
11px;font-face: Arial;vertical-align:sup;" class="--Webkit-custom-
property">a</span>" instead of  "<sup>a</sup>"?

Clearly this is something where either IMEs have to be made to insert the
exact same structures according to some standard, or, as an alternative,
the DOM change should not be final, but something the JS editor can change.


> > For example, I notice that with the only multi language keyboard on
> Android 5.1 (Multiling O Keyboard) with Chrome on standard sites such as
> Facebook, correcting previous comments is just fundamentally broken. In
> essence, the argument for why IME behavior needs to be standardized is the
> same argument for why anything needs to be specced and standardized and why
> we cannot just have 4-5 different browsers, each doing it's own thing in a
> different way.
>
> What we need is an abstraction which hides all these platform-dependent
> IME behaviors.  This is precisely why we've advocated for shadow-DOM like
> solution.  So that IME can do whatever it wants to without modifying the
> real DOM.
>
> On the contrary to what Ojan said during the meeting, I don't think we can
> make this new API completely backwards compatible with contenteditable in
> regards to IME if we wanted to accomplish our goal of browser not messing
> with DOM at all.
>

Ok, but as I understood the problem on the browser side, the
IME-in-shadow-DOM solution that was entirely in the browser was seen as
non-performant by Ojan. So instead a solution where the JavaScript could
handle this movement to the Shadow DOM was proposed.

But then Firefox 41 was about to break the ability to move the caret to
somewhere else during compositionstart and it was explained that with a new
Windows 10 IME [1] moving the caret at compositionstart will no longer be
possible. So that sound as if our JavaScript based solution is dead as well.

So the question is then: If none of these alternatives work for the
browsers, what alternatives can we have?


I think, in general, the options for IME sound very different depending on
whether on one looks at it from the side of the browser or from the side of
the JS editor developer. For the browser makers, there is a big difference
between making IME behavior transparent or giving access to all the details
to the JS editor developer. On the other hand, for the JS editor developer,
it is mainly about the IME based input to behave in a predictable way, with
a preference for

A) getting atomic commits from IMEs and be able to control what kind of
content it will insert/edit
B) at a lower priority, be able to control the DOM structure of the IME
created/edited content during the composition process


Some JS editor people may prefer achieving A and B by letting them handle
all parts of the IME composition process, others by just letting the
browsers handle it all without letting the browser insert anything into the
DOM. But in the end either solution will work.


[1] https://github.com/w3c/uievents/issues/5#issuecomment-137380446

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