composition events and focus changes

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.


DETAILS
I think it's clear that https://github.com/w3c/uievents/issues/5 would
address #2, but there are concerns on that issue that it would break #1.
Those concerns don't make sense to me. That's not because I think breaking
IMEs is OK (I don't!).

A. This is already how Safari and Chrome work. I can't find any bugs about
IME being broken due to this. It's not a problem in practice. And Firefox's
behavior here is clearly bad IMO (the IME stays open and you can keep
typing into it, but none of the changes are reflected in the DOM). I don't
have IE on hand to test what they do. I tested on Mac with a pinyin-based
IME. Here's my test case:
http://jsbin.com/povobotere/edit?html,console,output

B. Moving the selection in the DOM is only a problem if you move it to a
different text location. If you keep it in the same text location, but wrap
it in a span or put it inside a shadow DOM, then the IME continues working
as expected. Clearly there was agreement on the shadow DOM version of this
since there was previous agreement on magically doing this with shadow DOM
before.

The reason I don't think B is a problem is that there are a million other
ways of moving the selection mid-composition (e.g. you can move it during
keypress). We're not creating a new problem.

Also, it's only the really expert web developers that use composition
events. So good documentation can have a very big impact here. The best
thing we can do for better IME support on the web is to focus on creating
really great documentation about right and wrong ways to support IMEs.
Limiting composition events from doing something other events can already
do doesn't solve any problems.

Masayuki-san also had a concern on that bug that we'd be breaking
expectations of what composition events do because you wouldn't have a
guarantee of compositionend always firing on the same node compositionstart
fired on. I agree that's less than ideal, but it's consistent with other
events (e.g. key events). More importantly, it's how Safari and Chrome work
today and we have never once gotten a bug report about this that I know of.
It's just not a thing developers depend on or care about in practice.
Lastly, I'd like to reiterate that Mozilla's current behavior maintains the
compositionstart/compositionend pairing, but the user experience is really
broken. So there's no backwards compatibility concern here that I can see.

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