Re: composition events and focus changes

Hi Ojan,

Thanks for chiming in. I pretty much entirely agree with what you said. Just commenting on a couple of points inline.

> I'm making two key assumptions:
> 1. Keeping IMEs working correctly is non-negotiable. Any API we design needs to work correctly to the extent that is reasonably possible. That doesn't mean that every combination of actions needs to do what a user expects. For example, even in a non-IME world, a JS author can do crazy things on every keypress. There is no way to guard against that. There's not even a way to make that hard to do.
> 
> I'm not 100% sure, but I believe that this *does* imply that we can't make preventDefault work for all IME input.
> 
> 2. Giving JS authors complete control over DOM modifications is non-negotiable. Any author who has worked on a JS library can see the desperate need for this. It's just fundamental to having a decent editing platform. This does not, however, mean that the author needs to be able to preventDefault all actions.

100% agree on both points. I hope we all agree on that, otherwise I don't see how we will be able to reach a conclusion.


> So, I think there are two things that need specifying here and IMO in both cases the Safari and Chrome behavior is really reasonable:
> 1. What happens when you move focus during composition start? == The composition starts where you moved the focus to.

Yes, I strongly agree with this. Experience with the Chrome and Safari implementations prove that it is possible, and it satisfies the goals above. If anyone disagrees that this is the best way to solve the problem, please give an alternative proposal that still satisfies both assumptions above.

> 2. What happens when you move focus and there is a composition in progress? == The current composition is committed and a new composition starts where focus was moved to, but contains all the previous composition text as well. This has the advantage of not messing with the IME's internal state too much since the composition text doesn't change.
> 
> #2 is a thing people really shouldn't be doing, but we may as well agree on the best we can do here, which the current Safari/Chrome behavior seems pretty reasonable to me.

Probably. That sounds like a sane model. That said, this seems to be error case handling, so I don't strongly care what we agree to as long as we agree onto something

But don't we also need #3?
3. What happens when you move focus during composition end? == The current composition is pasted in the place where you moved the focus to.

Or did you include that as a subcase of #2, making 2 apply for composition updates and composition end?

 - Florian