Re: [w3c/editing] beforeinput should be fired only when the DOM change is caused by direct input by keypress or composition (#43)

@choniong @ojanvafai @dtapuska It has been a while since I read through the above conversation the last time. The most important points for a JS developer seem to be how a beforeinput event can be useful. From the above I can see two practical basic use cases:

1) To cancel the editing action the browser is about to make.

2) To record the current state of things before letting the browser do its editing (for undo, etc.)

There may also be a third option that seems to have been mentioned a few times in the past:

3) To have the JS editor developer define their own beforeinput events and then have other parts of their code react to those and in this way make beforeinput events an integrated part of their programming.

For usecase 3, it may make sense to trigger a beforeinput event for somethign the JavaScript itself has triggered. But: We kind of threw usecase 3 out a while ago. There is no reason to try to redefine the entire world in terms of beforeinput events and there are already lots of useful JavaScirpt ways of doing that.

For usecases 1 and 2, it does not seem to make any sense to trigger beforeinput events for things that the JavaScript itself has caused. 

I would therefore argue that it's ok for the input event to be triggered after execCommand (execCommand behavior continues not being well-specced), but let's not also add a lot fo new non-cancelable beforeinput events. That will only make life more complicated for JS develoeprs. Right now they can count on every beforeinput being cancelable except within an IME session. Let's not make it more complex than that.

---
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/43#issuecomment-227254358