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