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.

What part is unclear to you? Have you looked at the two examples linked above? They contain instructions on how they are to function and you can see the use case from them.

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

Can you elaborate a bit about that? Currently this is working quite well in Chrome Desktop at least on Mac OS X and Linux (on Android the compositionend event seems to be triggered immediately after compositionstart takes places). So I don't understand what you are trying to say with " client-side Shadow DOM library will not help the goal ". It's using the browser's native Shadow DOM implementation (no polyfill or clientside library). Shadow DOM isn't yet available everywhere, so when it isn't available, one can use the second example code.

> 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 is a petty that you weren't at the editing taskforce F2F meeting. The current spec allows for what we need. Now you are talking about changing the spec to disallow it? That does not sound like a good way forward, and if the goal was to get first-class IME support, this seems to instead just make it rather impossible to give IME in many webbased editors.

Do you have any alternative suggestion as to how to obtain the same result? 

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

Received on Thursday, 3 September 2015 09:53:25 UTC