Re: composition events and focus changes

On Sun, Oct 18, 2015 at 10:22 PM Florian Rivoal <florian@rivoal.net> wrote:

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

Nope. You're right. I forgot about case #3.


>
>  - Florian
>