yet another proposal

Not a new proposal, but a possible strategy to move forward on two fronts
at once.

I propose that we do the following two in parallel:

1. Spec beforeInput/input and composition events to solve all the use cases
with contentEditable=true. beforeInput/input + preventDefault basically
gets you contentEditable=events, with the exception of IMEs since they
aren't always preventDefaultable. For IMEs, composition events as currently
supported by Blink and Webkit solves the DOM control problem. We should
spec the Blink/Webkit behavior and encourage other browser vendors to
implement. See my previous email for why I think the Blink/Webkit behavior
makes sense.

We're very close to done here. I think we just need to:
-agree on the names
-agree on the composition event behavior
-complete the list of editing types

Note: I haven't had a chance to test Edge and/or other IE behavior here yet.

2. Pursue figuring out the details of Ryosuke's recent proposal to see if
it's something we can make work. The devil will be in the details and we'll
just have to talk through the implications. At first glance, it seems
plausible to me. This will have the advantage of being simpler for web
authors since they don't need to do the preventDefault (for non-IME) and
input isolation (for IME). I also like this because it moves closer to a
world in which we expose the guts of the editing richness from the
underlying platform.

For tomorrow's meeting, can we focus on hashing out #1 completely before
moving on to #2? I'd really like for Chrome to implement beforeInput ASAP*
and would like to codify the composition event behavior ASAP. Those are
blocked only on #1.

* I recently found out the Medium's primary blocker for making a mobile web
editor would have been solved by beforeInput.