Re: IME endcomposition event imeplementation inconsistencies

Hey

On Mon, Aug 31, 2015 at 5:06 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

>
> > On Aug 26, 2015, at 7:32 AM, Johannes Wilm <mail@johanneswilm.org>
> wrote:
> >
>
...

> >
> > What I am trying to achieve is to not have the composition insert
> anything into the DOM of the element before the entire composition is done.
>
> I don’t think that’s possible given our new design to insert the character
> directly into the text node instead of an implicitly created shadow DOM.
> There is no way for UAs to draw currently composing text inline without
> modifying DOM.
>

My understanding from the meeting was that this should be possible by
moving the caret manually into the Shadow DOM -- and my initial tests show
that this is possible (on Chrome/Linux with and Anthy IME). I have updated
the example code to make it clearer how to use it and so the code is a bit
more readable [1].


>
> > On the W3C Editing Taskforce we are trying to make it possible to give
> more direct control to JS on what changes are made to cE-elements and as
> part of that, one may choose to move the caret to somewhere else during
> composition.
>
> If that’s desirable, then we probably need to spec Chrome/Safari’s
> behavior, not Firefox’s.
>

I agree that Chrome/Safari's behavior will make it easier for the JS script
authors to achieve this effect than Firefox'es behavior. The most important
is that they behave the same way though.


>
> > Doing the composition in an alternative element works in both Chrome and
> Firefox, but due to above mentioned implementation differences, one has to
> write some of the code twice [2]. The idea is to eventually do what one can
> already do with Chrome [3] and compose characters inline without doing any
> changes to the DOM before the construction is entirely done.
>
> Again, I don’t think you can avoid making changes to DOM.  The very
> mechanism by which IME shows text to the user is by inserting text directly
> into the DOM if you’re moving the caret/selection to elsewhere,
> Chrome/Safari are removing the previously inserted composing text and
> inserting the confirmed composition into the final destination, not that it
> hand’t ever modified the text until the composition is confirmed.
>

Sorry, for me there is a big difference between changes in the traditional
DOM and in the Shadow DOM. What my example code is able to achieve is to
not have any changes in the traditional DOM by moving the caret into the
Shadow DOM.

The other example, which works on Firefox, does change the traditional DOM,
but not the part that represents the document the user is editing, which is
less problematic from the viewpoint of the JS editor. The character
construction does now happen inline though. [2]

[1] http://jsbin.com/pacisugiwu/1/edit?html,js,output
[2] http://jsbin.com/degubomera/1/edit?html,js,output

-- 
Johannes Wilm
http://www.johanneswilm.org
tel: +1 (520) 399 8880