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

I still don't see the connection of what you're trying to do and the high level goals.

Fixing collaborative editing environments on browsers was the motivation of the Shadow DOM discussion, so I agree with the goal. But client-side Shadow DOM library will not help the goal as far as I understand. I don't know about the other goal; a clientside undo history, so I can't comment on it.

@ojanvafai knows Blink far much better than I do, so if he's against, I'm happy to follow. There should be side effects by making IME transparent or opt-in, I have to admit that I don't know all of them yet, and he should know them in depth.

So, if all other vendors are happy, and JS developers are happy, it just means that collaborative editing on browsers must support IME explicitly, or they'll be broken, as current all offerings are. It's not a disaster.

Back to the original topic, I'm still not convinced that defining the behavior of moving selections during compositions is a good thing. IME is still evolving to make better UX, and platforms do it differently. Android relies on it heavily, and OS X is going to change the UX in the next version. I'd like to avoid defining it so that we can allow platforms and IME to evolve further.

It may be possible to define it without limiting platforms and IME evolutions, but I suspect it's not an easy task. If it's really desired, I'd like to understand the use case better, and how defining it can help the use case.

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