W3C home > Mailing lists > Public > public-editing-tf@w3.org > February 2017

Re: 2 Proposals for Minimum Viable InputEvent

From: Piotr Koszuliński <p.koszulinski@cksource.com>
Date: Mon, 13 Feb 2017 22:11:02 +0100
Message-ID: <CAFk9newGNq6eHLM322FkXJ2gLzWZrNBovZ6niN77EocCxhV15A@mail.gmail.com>
To: Alexandre Elias <aelias@google.com>
Cc: Johannes Wilm <johannes@fiduswriter.org>, Chong Zhang <chongz@chromium.org>, Dave Tapuska <dtapuska@chromium.org>, "public-editing-tf@w3.org" <public-editing-tf@w3.org>
>
> 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.
Received on Monday, 13 February 2017 21:12:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 February 2017 21:12:07 UTC