The default action of `beforeinput` does not define `<input>` and `<textarea>` cases

[masayuki-nakano]

https://w3c.github.io/input-events/#event-type-beforeinput

Currently, it's talking about only contenteditable and EditContext.

• For contentEditable=typing editing hosts for inputTypes "insertCompositionText" and "deleteCompositionText": 'Update the DOM'.
• For contentEditable="true" editing hosts for all inputTypes: 'Update the DOM'.
• For EditContext editing hosts for EditContext-handled inputTypes: Handle input for EditContext given the editing host element.
• None otherwise.

So, it does not define about <input> and <textarea>.

[vlakoff]

For context, see:

• Firefox ticket: 1909539 - preventDefault() in "beforeinput" event handler doesn't avoid form submission
• Chromium ticket: 355482873 - Preventing beforeinput of insertLineBreak in <input> prevents to submit the form by pressing Enter key

[johanneswilm]

• None otherwise.

Well, it does say "None otherwise" so that should cover all those not mentioned previously. So basically the ~dom~ value change and the before input event are not related in those cases. However, it sounds like that is not how it is implemented and not what is expected. So I agree we should probably make some change here.

[smaug----]

https://issues.chromium.org/issues/40948436 is also related. It changed recently the behavior in Chrome so that one can call preventDefault() when changing type=number values using the spin buttons (assuming I understood it correctly).

UIEvents spec has a bit different definition: https://w3c.github.io/uievents/#event-type-beforeinput Based on that the target at least can be input or textarea (although that is quite vaguely said), but it still talks about DOM being updated. Form controls' value isn't part of the DOM tree.

[johanneswilm]

From TPAC 2024 minutes:

RESOLUTION: for relevant input types and textarea, the default action should update the value and it’s cancelable. Browser makers find out which input types this should apply to (Olli will test).

[vlakoff]

This is still unclear to me:

the default action should update the value and it’s cancelable

When pressing Enter in an \<input> (which is single-line), it doesn't insert a newline, thus it doesn't change the value. Therefore, this action is not the default one. Here the action is universally to submit the form.

So, is it also in the scope of "cancelable" from the quote? I would tend to say yes.

Let me rephrase the quote to show how I perceive it:

The action is by default to update the value. The action is cancelable.

Also, as a reminder, the arguments I had posted in my comment 7 on Bugzilla:

• Users expect that preventDefault() does what is written on the tin: discards browser actions, as if the browser is no longer seeing the key input.
• That's what keypress and keydown do. But the former is deprecated, and the latter is less adequate, being about physical keyboard.
• Using a beforeinput event (which is the recommended one), if removing the preventDefault() way, there would be no other way to avoid form submission…