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

@masayuki-nakano 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.

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.

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. For example, changing focus during keydown causes keyup to fire on a different element. http://jsbin.com/kuvupalile/edit?html,console,output

There's a legitimate use-case for the behavior @johanneswilm is asking for.

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

Received on Thursday, 3 September 2015 07:46:12 UTC