W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2015

Re: IME endcomposition event imeplementation inconsistencies

From: Ryosuke Niwa <rniwa@apple.com>
Date: Mon, 31 Aug 2015 08:06:18 -0700
Cc: www-dom@w3.org, Gary Kačmarčík <garykac@google.com>, Travis Leithead <travis.leithead@microsoft.com>, "public-editing-tf@w3.org" <public-editing-tf@w3.org>
Message-id: <F42C5DBF-7C1F-4467-921D-3B894800485A@apple.com>
To: Johannes Wilm <mail@johanneswilm.org>

> On Aug 26, 2015, at 7:32 AM, Johannes Wilm <mail@johanneswilm.org> wrote:
> 
> Hey,
> I noticed that the IME compositionend event is implement somewhat differently in Chrome and Firefox. Looking at the spec [1], I am not sure if either of them are correct.
> 
> Chrome triggers the event on the element where the caret currently is, if one moves it to another contentEditable element it then pastes all the composed characters there.
> 
> Firefox triggers the event on the element where the caret was at the time when the compositionstart event was triggered. It does not paste the composed characters into another cE-element, if one places it there.
> 
> 
> The spec seems to say that it has to be triggered on the element where the composition actually takes place. I don't think it says it should paste the composition in another place if the caret is moved there, but this actually helps my use case.
> 
> 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.

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

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

- R. Niwa
Received on Monday, 31 August 2015 15:07:12 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 10:46:24 UTC