Open masayuki-nakano opened 3 months ago
For context, see:
- 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.
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.
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).
https://w3c.github.io/input-events/#event-type-beforeinput
Currently, it's talking about only
contenteditable
andEditContext
.So, it does not define about
<input>
and<textarea>
.