Re: 2 Proposals for Minimum Viable InputEvent

Great!
Basically it just seems to come down to 3 proposals in concerns of the
start of the IME operation:

1. A merged proposal of the various bits that have cone from Google with
some parts still to be clarified.

2. Keep things as they are.

3. Merge the first two beforeinput events, but make them cancelable.

As for the end of IME, I can see two proposals:

1. Google's merged proposal with some things to be clarified.

2. Keep things as they are.

And for other input events, I see three proposals:

1. Google's merged proposal with more things to be clarified.

2. Keep things as they are.

3. Make beforeinput events cancelable when they affect complex content,
otherwise have them cancelable.


If 2 or 3 are fine for everyone in each case, we can probably decide on
something tomorrow. If 1 is still on the table for any of these, we will
probably need more time to think this through and we'll probably also need
more meetings about these proposals.

I don't think anyone should have to lose their holiday over this.

On 13 Feb 2017 6:11 p.m., "Piotr Koszuliński" <p.koszulinski@cksource.com>
wrote:

> On the other hand, Piotr stated that the conservative proposal still
>> allows "a pretty significant simplification, comparing to what we have
>> to do now." so it sounds like non-cancelable IME beforeinput still would
>> provide value to editors, while being relatively painless and risk-free for
>> UAs.
>>
>> So personally, I'm increasingly convinced after chewing on the discussion
>> so far that our proposal (plus those two 2 additional tweaks) is the best
>> way forward for everyone.
>>
>>
> I'd like to underline one bit here – the more conservative proposal has
> chance to succeed, but there are some details we must get right. AFAICS
> right now, it boils down to letting JS editors pre-act on beforeinput
> without stopping the browser/IME from continuing with the text insertion.
> The only exception from this rule could be beforeinput events fired during
> composition (if there will be any) because, as we know, we can't change the
> DOM at that stage anyway to not break the composition.
>
> From what I understand, the proposal 3 doesn't clarify this.
>
> PS. We're right now "pre-acting" on keydown events with a good results,
> so, at least we can do something up to this moment.
> PPS. I'll try to attend tomorrow's call, but I'm on holidays (yeah,
> discussing IME :D) now and I can't guarantee that I'll have a stable
> connection. Sorry if I miss it.
>
>