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

Can you explain what issues there are in the current collaborative editing on browsers, and how your example can help solving those issues?

The idea Ben and I were discussing was an early stage of the discussion to make IME inputs completely transparent, similar to what IME level 2 API on Windows does. If we discard the idea, there are several things apps must do to handle IME. Simple apps may need no-to-few, but collaborative editing might need several. The Shadow DOM-like building block was one part of making IME transparent. If it's not transparent, it looks to me that whether composition occurs within Shadow DOM or not isn't a big issue.

If you have clear understanding of what the issues are, and seeing connections between your code and those issues, that's ok. I'm sorry if I'm wrong, but I wonder we (including me) don't have clear understanding on them, no?

If you do, and moving compositions along with selection is a required feature to solve the issues, I'm ok to have that. Me not having an understanding isn't a blocking factor.

But please keep in mind that the behavior you described has been considered as a very bad IME UX for a long period of time. Also it's likely to break re-conversion as mentioned above. We probably have to make sure it's allowed only when JS really needs it, but the behavior never be exposed otherwise.

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