Re: composition events and focus changes

On Tue, Oct 20, 2015 at 3:47 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

>
> > On Oct 19, 2015, at 1:26 PM, Ojan Vafai <ojan@google.com> wrote:
> >
> > I'd like to get us back from our state of questioning everything we're
> doing and focus on seeing if our current tack can be saved. IMO, we're very
> close to something finished and should try not to change course if we can.
> >
> > I would like to end up in a world where we spec low-level IME apis, but
> that's a big project and not one that we should take on without more
> staffing from a browser vendor committed to designing and implementing them.
> >
> > Here's the TL;DR of my preferred path forward:
> > 1. Spec the current Chrome/Safari behavior. This will make the JS
> authors happy and will not hurt IME in any way (see below for details).
> > 2. Publish good documentation about how to use composition events and
> about common pitfalls (e.g. moving the cursor to a different place in the
> text). This will both make JS authors happy and improve IME support on the
> web.
> >
> > 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.
>
> I also agree with both of these points.
>

I agree too.

There's one minor point I'd like to confirm our consensus.

What are our stance when 1 and 2 conflicts?

Giving JS authors complete control of whatever browsers have full control
over is in consensus.

During composition, however, IME owns some controls and there's nothing
browsers can do. Oftentimes IME is the master and browser is following its
orders. For instance, MDN[1] states that "some platforms don't have an API
for canceling composition." Some IME flushes compositions when system focus
is moved, so if we define behavior on focus move, we may need to make sure
system focus is not affected, but I'm not sure if this is possible on all
platforms at this moment.

For those possible platform differences, I prefer abstraction than giving
control so that JS works across platforms. In a big picture, this might be
a sub-item of Ojan's item 1, but it may be considered to hinder item 2 at
some levels. That's what I meant by "conflicts" above.

Thoughts?

[1] https://developer.mozilla.org/en/docs/Web/Events/compositionstart

/koji