Update Button and Input Activation behaviours #11053
Conversation
Reset buttons and inputs no longer trigger popover target activation behaviour. Reset buttons no longer trigger command button activation behaviour.
|
This PR introduces a 'breaking' change to When a button has a form owner (is inside form or has a valid form attribute). A) Button has a missing type attribute. F) Input has a type="submit" attribute. Table of behaviour when popovertarget is on each of these buttons.
Table of behaviour when command and commandfor is on each of these buttons (input cases N/A).
*** Invalid type buttons originally were intended to behave as submit buttons and like type=submit, but the spec made them auto buttons like missing type buttons, based on discussions in whatnot this also seems to be desired behaviour. |
lukewarlow
force-pushed
the
command-button-activation-changes
branch
from
9a01180 to
8bcbbf9
Compare
There was a problem hiding this comment.
I think this achieves the interim state described in #11044 (comment)
|
@zcorpan can I mark this as supportive from Mozilla's side? |
There was a problem hiding this comment.
@keithamus should double check this, but I don't think this needs separate implementer approvals as this was supposed to be part of the original PR.
This does include a change to popovertarget which wasn't part of the original but came from discussions in whatnot, so that aspect might do? |
|
Fair enough. You can consider WebKit interested. cc @nt1m |
|
This is OK for Mozilla. |
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 <chromium@keithcirkel.co.uk> Reviewed-by: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1425642}
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 <chromium@keithcirkel.co.uk> Reviewed-by: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1425642}
Update Button and Input Activation behaviours
Reset buttons and inputs no longer trigger popover target activation behaviour when there's a form owner.
Reset buttons no longer trigger command button activation behaviour when there's a form owner.
Missing and invalid type buttons no longer trigger command button activation behaviour when there's a form owner.
(See WHATWG Working Mode: Changes for more details.)
/form-elements.html ( diff )
/input.html ( diff )