Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
masayuki-nakano opened this issue Jul 26, 2024 · 5 comments

Comments

@masayuki-nakano
Copy link

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

@johanneswilm
Copy link
Contributor

johanneswilm commented Jul 26, 2024

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

@johanneswilm johanneswilm added the Agenda+ Queue this item for discussion at the next WG meeting label Jul 26, 2024
@smaug----
Copy link

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
Copy link
Contributor

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

@johanneswilm johanneswilm removed the Agenda+ Queue this item for discussion at the next WG meeting label Oct 7, 2024
@vlakoff
Copy link

vlakoff commented Nov 17, 2024

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…

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants