Unclear when input events are triggered

[johanneswilm]

As part of the TAG review of the Input Events spec, it was mentioned that the beforeinput event would be useful also for input elements. That has of course been the point already, but it does not seem clear from the spec under what circumstances the events are actually fired. In the UI Events spec, it says:

"Input events are sent as notifications whenever the DOM is being updated."

That seems too broad -- when some JavaScript triggers a DOM change, that should not trigger beforeinput/input events.

In the current editor's draft of the Input events spec it says:

"Input events are sent before (beforeinput event) and after (input event) a user attempts to edit the markup. This includes insertion and deletion of content, and formatting changes.

Input events are dispatched on elements that act as editing hosts, including elements with the contenteditable attribute set, textarea elements and input elements that permit text input."

Could we come up with a text that we can all agree on?

Any thoughts, @garykac, @travisleithead?

[ayg]

Why are these events specced in two places? Which is authoritative?

Should they be fired for execCommand()? Normally this corresponds to a user action as well, e.g., Ctrl-B triggering execCommand("bold"). (I think WebKit/Blink will fire this from the browser.) Implementation-wise, it's easier to not distinguish between actual user input and insertText, for instance. Certainly direct DOM manipulation should not fire them.

@masayuki-nakano @rniwa (who does editing at Blink?)

I'm trying to implement .data on input events now for Firefox, and without a clear spec it's rather hard. Good tests would make it far easier, but wpt doesn't support synthesizing user input yet. :(

[ayg]

Also, is beforeinput supposed to be fired every time input is? Chrome fires input for execCommand()s, but not beforeinput.

[johanneswilm]

Why are these events specced in two places? Which is authoritative?

The event was divided into two parts. The event is mentioned in the UI events spec, but everything important about the event is in the input events spec. I am not sure why this division was made, but now we have it. What is important though is that it is clear when the event is being triggered. The Input Events spec should now contain a reasonable explanation.

[garykac]

@johanneswilm Please review and let me know if you think any changes are necessary. Thanks!

[masayuki-nakano]

Oops, I'm really sorry, I forgot to reply.

@ayg When I discussed if it should fire "input"/"beforeinput" events for the changes by JS, the conclusion was "shouldn't be fired" and "at least, beforeinput shouldn't be cancelable". The main reason of that was, triggering input/beforeinput from JS can cause security issue easily. I don't know "current" decision for this issue.