Lift restriction on buttons with implicit type=submit and command/commandfor being no-op
#10832
Labels
addition/proposal
New features or enhancements
needs implementer interest
Moving the issue forward requires implementers to express interest
topic: forms
Comments
keithamus
added
addition/proposal
keithamus
changed the title
type=submit and command/commandfor is ambiguoustype=submit and command/commandfor being no-op
6 tasks
|
Note this also now applies to |
aarongable
pushed a commit
to chromium/chromium
that referenced
this issue
Feb 27, 2025
This change does a few things to align with the latest spec, based on the changes in whatwg/html#11053. - Reset buttons should _only_ reset the form, not trigger additional popover or command behaviours. - Buttons should reflect "button" when command/commandfor attributes are present, with or without a form-owner. - Buttons that reflect "button" with command/commandfor attributes that have a form-owner should be no-op; this is a restriction for back-compat that will eventually be lifted. whatwg/html#10832 tracks the state of this, and consequently I've added a UseCounter to help figure out when it is safe to make this change. Bug: 399124617 Change-Id: I684371bb7fc8e0888bcf0713caff212f4806a7c4 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6304979 Commit-Queue: Keith Cirkel <[email protected]> Reviewed-by: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1425642}
WeizhongX
added a commit
to web-platform-tests/wpt
that referenced
this issue
Feb 27, 2025
This change does a few things to align with the latest spec, based on the changes in whatwg/html#11053. - Reset buttons should _only_ reset the form, not trigger additional popover or command behaviours. - Buttons should reflect "button" when command/commandfor attributes are present, with or without a form-owner. - Buttons that reflect "button" with command/commandfor attributes that have a form-owner should be no-op; this is a restriction for back-compat that will eventually be lifted. whatwg/html#10832 tracks the state of this, and consequently I've added a UseCounter to help figure out when it is safe to make this change. Bug: 399124617 Change-Id: I684371bb7fc8e0888bcf0713caff212f4806a7c4 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6304979 Commit-Queue: Keith Cirkel <[email protected]> Reviewed-by: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1425642}
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What is the issue with the HTML Standard?
With #9841 it is possible to author a
commandforbutton inside a form, with the expectation that it will trigger the command. However based on the discussions in #9625 (comment) we opted to make a<form><button commandfor=>..a no-op, instead encouraging users to addtype=buttonto make it work. This is to prevent compatibility issues with old browsers which will end up submitting the form as they don't recogniser thecommandfor=attribute.This issue tracks an eventual goal of lifting this restriction, such that
<form><button commandfor=>..works like a invoker command button, rather than a no-op. We can lift this restriction when there is sufficiently low compat risk, which we estimate may be in ~5 years time.This relates to #10462.
The text was updated successfully, but these errors were encountered: