Re: yet another proposal

I agree. BeforeInput gives us a lot already and this shouldn't break
anything. Ryosuke recently proposed to add all the execCommands as
editTypes. Everyone ok with that?
We can then additionally say that if a browser adds new editing behavior
that does change the DOM, but doesn't correspond to any of the specced
editTypes, they still have to trigger a beforeInput event. The editType for
that can be "unknown" or a word the browser makes up. The goal will then of
course be to spec such new editTypes ASAP.

As for the presentation in the web platform WG: thanks to Koji, Ryosuke and
Chaals for helping out there.

Also some interesting thoughts on the underlining problem Ryosuke
explained. It almost seems the underlining could be handled in JS/CSS -
except that the words that are composed often just correspond to partial
elements and therefore cannot be targeted by CSS Selectors. And forcing
editors to create a new element to do their composition in is likely not
acceptable.

So altogether it seems Ryosuke is the cleanest way of doing it we can get
for now. But I think Ojan is also right and recent experience shows us that
we often find issues when looking into the details. So lets aim on
resolving the IME stuff in the near future, but not necessarily tomorrow.
On 27 Oct 2015 12:09 pm, "Ojan Vafai" <ojan@google.com> wrote:

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