Re: IME endcomposition event imeplementation inconsistencies

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?

________________________________________
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

Received on Tuesday, 1 September 2015 02:11:37 UTC