Re: [uievents] specify how compositionend works if the caret has been moved to a different element (#5)

>  the use-case is to be able to move the focus into a shadow DOM inside the contentEditable. It would go in the same location in the DOM, so the IME would have the same text content to work with. It gives the web author a way of ensuring that the DOM changes from a composition only go into the DOM at compositionend as an atomic commit.
> 
> Before this suggestion, the contentEditable spec required the UA to do this shadow DOM behavior. I objected to that and pointed out that authors can already do this in script.
> 
> Even if you ignore shadow DOM, you could imagine putting it in a span inside the regular DOM, but in the same location. So the IME prediction would work the same, but the author would have full control over the DOM.

Although, I don't understand what "the use-case" you said indicates.

Thank you for your explain. I'm not familiar with "How Firefox treats shadow DOM", though, The last example is interesting. IIRC, starting Firefox 43, it won't commit/cancel composition even if selection is changed but the offset in the text isn't actually changed. So, the last example must work even on Firefox 43 for Windows or Linux. (IIRC, Firefox for Mac doesn't have this problem)

FYI: the testcase http://jsbin.com/wimuqowimu/15/edit?html,js,console,output won't work fine on Firefox 41 for Windows, unfortunately. Firefox 41 starts to support TSF on Windows. TSF is very rich framework, but very sensitive. For example, TSF doesn't allow to happen selection change/text change in focused editor at composition start. However, Firefox caches the previous contents of focused editor and lies TSF when it tries to query the content. If TSF-aware application returns unexpected content, TSF or some TIP (IME for TSF) may stop working :-( Anyway, I'll try to fix this bug latter...

> Does that use-case sound legitimate to you? I believe the IME would function exactly the same in all these cases. It's true that if you don't know what you're doing, you can mess this up, but that's true today too. You can just as easily mess with the DOM in other ways that will break IME prediction.

If you said about http://jsbin.com/wimuqowimu/15/edit?html,js,console,output , this wants more hack for Firefox developers... I'm not sure if this can be fixed easy.

> Regarding compositionend happening on the same element compositionstart happens on, why is that important? From a conceptual level, there are already plenty of instances where moving focus will cause the start/end events of a certain type to not fire on the same element.

The main reason of that is, some web apps may work stateful with compositionstart/compositionend. For example, if web apps need to handle input only when the focused editor doesn't have composition, they need to make a flag to store if there is composition with compositionstart and compositionend events. If such web apps fails to listen one of them, their input event handler won't work as expected. For making such web apps stateless, I suggested isComposing attribute to InputEvent, but the browsers except Firefox have not supported it yet.

Additionally, I believe that compositionstart, compositionupdate and compositionend are events of existing composition. Therefore, I believe that it makes sense the events fired on an element which includes the composition.

If a browser doesn't commit composition even when the element loses focus but the composition is committed by other reason (e.g., destroying the element), why should composition events be fired on focused element? If they are always fired on an element which has composition, such scenario can be fixed simply.

> For example, changing focus during keydown causes keyup to fire on a different element.

Yeah, right. But I feel that it makes sense that keyboard events are always fired on focused element because a focused element is a receiver element of keyboard event at the time. The difference of composition events are, the events are fired for notifying web apps of the composition state changes. Therefore, an element which has composition string should receive it.

---
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/issues/5#issuecomment-137380446