Re: 2 Proposals for Minimum Viable InputEvent

> On Feb 8, 2017, at 14:41, Ojan Vafai <ojan@google.com> wrote:
> 
> My preference is that we move forward with making the subset of insert and delete types I suggested in my earlier email uncancellable in v1 and then do a proper exploration of what platforms and contexts we could potentially make all inputTypes cancellable.
> 
> Up until now, we've mostly worked off lore of what's possible. With one exception, Masayuki from Mozilla explained to us that the latest iteration of IME APIs on Windows are never cancellable IIRC.
> 
> It may be the case that once we have a good grasp of the situation on all platforms we would reconsider whether we could make all eventTypes cancellable on some platforms.

I am confused. I thought the entire point of beforeInput was to be cancelable, so that js could reason about the DOM without having it change in unexpected ways. Whether the js use that to outright cancel a few operations it disapproves of, does some of the DOM mutations on its own to do them differently, or does everything on its own because it has a separate model of the document which it is merely rendering to the DOM is up to the js author, but the result is ultimately the same: preventing the DOM from changing into a state that the js does not know how to handle.

Regardless of the amount and complexity of the scripts, contentEditable is not used without scripts, so making sure we don't end up with DOMs the scripts don't know how to handle seems essential. Yes, IMEs make this a lot more complicated, but the goal should still be to leave the js author in charge, since they ultimately are the ones who need to deal with the result.

Or did I misunderstand something?

—Florian

Received on Wednesday, 8 February 2017 09:17:21 UTC