Re: IME endcomposition event imeplementation inconsistencies

On Tue, Sep 1, 2015 at 4:11 AM, Grisha Lyukshin <glyuk@microsoft.com> wrote:

> I ran modified example in MS Edge and it somewhat resembles of what FF
> does. Should we create an issue to spec composition behavior then?
>

Exactly. I have now filed a bug here:
https://github.com/w3c/uievents/issues/5


>
> ________________________________________
> From: Ryosuke Niwa <rniwa@apple.com>
> Sent: Monday, August 31, 2015 9:25 AM
> To: Johannes Wilm
> Cc: www-dom@w3.org; Gary Kačmarčík; Travis Leithead;
> public-editing-tf@w3.org
> Subject: Re: IME endcomposition event imeplementation inconsistencies
>
> > On Aug 31, 2015, at 9:15 AM, Johannes Wilm <mail@johanneswilm.org>
> wrote:
> >
> > 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].
>
> Ah, I see. Yeah, that should work.
>
> >>
> >> > 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]
>
> I guess we need to spec what exactly happens (where composing text is
> inserted) when the selection is moved inside compositionstart.
>
> - R. Niwa
>
>
>


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