Re: composition events and focus changes

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

- R. Niwa

Received on Tuesday, 20 October 2015 06:48:26 UTC