Re: composition events and focus changes

> On Oct 20, 2015, at 6:37 PM, Koji Ishii <kojiishi@gmail.com> wrote:
> 
> 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.

I don't think we can come to a general consensus on this matter without specifics.

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

On this specific issue, it seems that we should end the composition on such platforms. We can do this without hindering JS's ability to control DOM by first canceling the composition, then changing the focus.

I don't think if we can give JS the ability prevent the cancelation of the composition if that's what you're referring to by "conflicts".

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

I agree on that general principle.  We should be minimizing the platform-dependent behaviors as much as possible.

- R. Niwa

Received on Tuesday, 20 October 2015 10:41:46 UTC