Add commandfor & command attributes to HTMLButtonElement #9841

keithamus · 2023-10-08T23:00:35Z

This adds the commandfor & command attributes and a "command" event using the CommandEvent interface.

Button activation checks if the button has a "commandfor" target and if so performs invoker command behaviour depending on command and the target element.

Some related (eventual) follow up issues around this feature:

Investigate making the invalid state of <button type> _not_ submit #10462; Investigate making the invalid state of <button type> not submit
Lift restriction on buttons with implicit type=submit and command/commandfor being no-op #10832; Lift restriction on buttons with implicit type=submit and command/commandfor being no-op
At least two implementers are interested (and none opposed):
- Mozilla Supportive & prototyping
- Webkit
- Chromium supportive; actively prototyping.
Tests are written and can be reviewed and commented upon at:
- Mark invokers tests as non-tentative web-platform-tests/wpt#42664 (PR to make the tests non-tentative)
Implementation bugs are filed:
- Chromium Bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1490919
- Chromium Patch: https://chromium-review.googlesource.com/c/chromium/src/+/4926471
- Gecko Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1856430
- Gecko Patch: https://phabricator.services.mozilla.com/D190449
- WebKit Bug: https://bugs.webkit.org/show_bug.cgi?id=262840
- Webkit Patch: Add invoketarget & invokeaction attributes WebKit/WebKit#18794
MDN issue is filed: Add documentation for the "command" and "commandfor" attributes, and "command" event. mdn/content#30829
The top of this comment includes a clear commit message to use.
a11y & i18n are considered and relevant PRs are created: Add command & commandfor attribute related mappings w3c/aria#2354

(See WHATWG Working Mode: Changes for more details.)

/dom.html ( diff )
/form-elements.html ( diff )
/index.html ( diff )
/indices.html ( diff )
/interaction.html ( diff )
/interactive-elements.html ( diff )
/webappapis.html ( diff )

scottaohara · 2023-10-18T16:54:02Z

I realize this is also in the steps for getting the popover target element, but in both cases I'm wondering why its specified to return null if the node is in the disable state?

Doing so, at least with <button popovertarget=foo disabled> testing in chrome, results in that element not exposing whether the popover is in the expanded or collapsed state - as I'm assuming due to

"If node is disabled, then return null."

that state gets removed. That's unexpected, to have that state removed based on whether the button is disabled or not. And for invokertarget - if it is really is going to do more than just show/hide content - there are a lot of other states that should still be exposed, regarless of if the element is in the disabled state or not.

edit: I can file a bug for disabled / popovertarget if necessary - i just wanted to get insight on this first, before I went and made that issue. cc @mfreed7

See related spec PR whatwg/html#9841

lukewarlow · 2023-11-04T13:36:02Z

Fwiw HTML requires a positive standards position or for chrome LGTMs on an intent to ship to be considered supportive.

Saying that Mozilla have marked their position as positive so that's 1 implementor interested.

I do wonder how this requirement works for a feature such as this which will require multiple PRs to add to the spec?

domenic · 2023-11-05T00:52:12Z

a feature such as this which will require multiple PRs to add to the spec?

I'm confused why this feature is being done as multiple PRs; it makes review a good deal harder.

keithamus · 2023-11-05T01:03:00Z

If it makes it easier to review I’m happy to put more into one PR. I figured it would be worthwhile splitting it into the core vs each elements behaviour as I imagine there will be more to discuss with each elements behaviour.

domenic · 2023-11-05T01:04:05Z

Well, it'd make it easier for me, but I haven't signed up to review yet, so no need to make any changes until we get some more opinions :)

Edited to add: the reason it makes it more difficult is that I don't think we want to accept the feature piecemeal.

lukewarlow · 2023-12-01T21:07:17Z

As per openui/open-ui#900 (comment) this'll need updating to only fire the event when the action is custom (has a hypen) or is recognised and valid (correct action name on correct element).

TLDR is that this will allow us to add default actions in future without conflicting with user land code.

lukewarlow · 2023-12-01T21:09:24Z

In openui/open-ui#952 (comment) we resolved that "Invokers v1 will be popover and dialog invoking."

This should help keep this initial PR as small as possible while also avoid the issue of reviewing stuff piecemeal.

So #9875 can be merged into this along with dialog related changes.

mfreed7 · 2024-01-17T22:12:20Z

Fwiw HTML requires a positive standards position or for chrome LGTMs on an intent to ship to be considered supportive.

Saying that Mozilla have marked their position as positive so that's 1 implementor interested.

Chromium is explicitly supportive of this proposal, so I believe it has two implementer support (including Mozilla).

Is this PR in a state that it can get a review? I'm happy to do so, if it'd help.

keithamus · 2024-01-17T22:47:01Z

I'd be happy to get reviews, I think this is in a good position for that.

source

mfreed7 · 2024-01-17T23:09:42Z

I'd be happy to get reviews, I think this is in a good position for that.

Done - I added a first set of comments.

source

annevk · 2024-12-04T07:59:52Z

As asked on Chat, is there an a11y PR for this?

annevk

There's quite a bit more wrapping nits I see, but I will do a cleanup pass once these and the a11y question are addressed and OP is complete (haven't checked).

source

keithamus · 2024-12-04T09:11:04Z

As asked on Chat, is there an a11y PR for this?

There is: w3c/aria#2354, but it'll need a little reword due to how we've worked the logic for buttons.

In whatwg/html#9841 the behaviour for commandfor= as a form owner has subtly changed: - <button commandfor=> (implicit submit) that has a form owner now does nothing (so we will log a warning to the console telling the user that this is the case and they should add `type=button` to make it a command button). - <button type=reset command..> and <button type=submit command..> that have a form owner should do the behaviour explicitly laid out by their `type`, and ignore and `command`/`commandfor` attributes semantics. In this case we log a warning to the console telling the user that the command/commandfor are being ignored. To keep changes light here, only the DefaultEventHandler/CommandForElement logic has changed; a more significant refactor might be needed to adjust `type_` to ensure it does not resolve to `kSubmit` implicitly, but that should be handled more delicately, I believe. Bug: 382238696 Change-Id: I7d5583d34a2d615faeed80905816edb3f261d60d

In whatwg/html#9841 the behaviour for commandfor= as a form owner has subtly changed: - <button commandfor=> (implicit submit) that has a form owner now does nothing (so we will log a warning to the console telling the user that this is the case and they should add `type=button` to make it a command button). - <button type=reset command..> and <button type=submit command..> that have a form owner should do the behaviour explicitly laid out by their `type`, and ignore and `command`/`commandfor` attributes semantics. In this case we log a warning to the console telling the user that the command/commandfor are being ignored. To keep changes light here, only the DefaultEventHandler/CommandForElement logic has changed; a more significant refactor might be needed to adjust `type_` to ensure it does not resolve to `kSubmit` implicitly, but that should be handled more delicately, I believe. Bug: 382238696 Change-Id: I7d5583d34a2d615faeed80905816edb3f261d60d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6070260 Auto-Submit: Keith Cirkel <[email protected]> Reviewed-by: Mason Freed <[email protected]> Commit-Queue: Keith Cirkel <[email protected]> Cr-Commit-Position: refs/heads/main@{#1393810}

…r combinations, a=testonly Automatic update from web-platform-tests Re-design logic for commandfor form-owner combinations In whatwg/html#9841 the behaviour for commandfor= as a form owner has subtly changed: - <button commandfor=> (implicit submit) that has a form owner now does nothing (so we will log a warning to the console telling the user that this is the case and they should add `type=button` to make it a command button). - <button type=reset command..> and <button type=submit command..> that have a form owner should do the behaviour explicitly laid out by their `type`, and ignore and `command`/`commandfor` attributes semantics. In this case we log a warning to the console telling the user that the command/commandfor are being ignored. To keep changes light here, only the DefaultEventHandler/CommandForElement logic has changed; a more significant refactor might be needed to adjust `type_` to ensure it does not resolve to `kSubmit` implicitly, but that should be handled more delicately, I believe. Bug: 382238696 Change-Id: I7d5583d34a2d615faeed80905816edb3f261d60d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6070260 Auto-Submit: Keith Cirkel <[email protected]> Reviewed-by: Mason Freed <[email protected]> Commit-Queue: Keith Cirkel <[email protected]> Cr-Commit-Position: refs/heads/main@{#1393810} -- wpt-commits: 3d3ea3af3e2049be17b4d881c957550c13637ba4 wpt-pr: 49594

…r combinations, a=testonly Automatic update from web-platform-tests Re-design logic for commandfor form-owner combinations In whatwg/html#9841 the behaviour for commandfor= as a form owner has subtly changed: - <button commandfor=> (implicit submit) that has a form owner now does nothing (so we will log a warning to the console telling the user that this is the case and they should add `type=button` to make it a command button). - <button type=reset command..> and <button type=submit command..> that have a form owner should do the behaviour explicitly laid out by their `type`, and ignore and `command`/`commandfor` attributes semantics. In this case we log a warning to the console telling the user that the command/commandfor are being ignored. To keep changes light here, only the DefaultEventHandler/CommandForElement logic has changed; a more significant refactor might be needed to adjust `type_` to ensure it does not resolve to `kSubmit` implicitly, but that should be handled more delicately, I believe. Bug: 382238696 Change-Id: I7d5583d34a2d615faeed80905816edb3f261d60d Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6070260 Auto-Submit: Keith Cirkel <chromiumkeithcirkel.co.uk> Reviewed-by: Mason Freed <masonfchromium.org> Commit-Queue: Keith Cirkel <chromiumkeithcirkel.co.uk> Cr-Commit-Position: refs/heads/main{#1393810} -- wpt-commits: 3d3ea3af3e2049be17b4d881c957550c13637ba4 wpt-pr: 49594 UltraBlame original commit: c8018e3c22b59bc1daf9a5bef312e955ba15bccb

This was referenced Oct 8, 2023

"command" and "commandfor" attributes WebKit/standards-positions#264

Closed

Invokers (invoketarget & invokeaction) mozilla/standards-positions#902

Closed

keithamus force-pushed the add-invoke branch from c004fd4 to 0c56df8 Compare October 9, 2023 09:31

keithamus changed the title ~~Add invoke~~ Add InvokeElement & InvokeEvent IDLs for Invoke proposal Oct 9, 2023

keithamus changed the title ~~Add InvokeElement & InvokeEvent IDLs for Invoke proposal~~ Add InvokeElement & InvokeEvent IDLs & invocation steps for Invoke proposal Oct 9, 2023

Schweinepriester mentioned this pull request Oct 10, 2023

Add Invokers, currently invoketarget & invokeaction Fyrd/caniuse#6856

Open

keithamus force-pushed the add-invoke branch from 0c56df8 to 98adb9f Compare October 10, 2023 22:26

keithamus marked this pull request as ready for review October 10, 2023 22:28

keithamus force-pushed the add-invoke branch 3 times, most recently from 45e4032 to 9579336 Compare October 17, 2023 20:32

This comment was marked as outdated.

Sign in to view

keithamus force-pushed the add-invoke branch 2 times, most recently from 7f0f9ea to 834a8b1 Compare October 18, 2023 21:36

keithamus mentioned this pull request Oct 20, 2023

Mark invokers tests as non-tentative web-platform-tests/wpt#42664

Open

keithamus added a commit to keithamus/wpt that referenced this pull request Oct 20, 2023

Mark invokers tests as non-tentative

858bcd8

See related spec PR whatwg/html#9841

keithamus force-pushed the add-invoke branch from 834a8b1 to bd64801 Compare November 1, 2023 12:30

keithamus mentioned this pull request Nov 9, 2023

refactor Dialog to use <dialog> internally primer/view_components#2364

Merged

10 tasks

keithamus mentioned this pull request Jan 11, 2024

Refactor Dialog to use <dialog> internally primer/view_components#2496

Merged

10 tasks

mfreed7 reviewed Jan 17, 2024

View reviewed changes

domfarolino reviewed Nov 28, 2024

View reviewed changes

source Show resolved Hide resolved

source Show resolved Hide resolved

source Show resolved Hide resolved

source Show resolved Hide resolved

source Show resolved Hide resolved

source Show resolved Hide resolved

source Show resolved Hide resolved

redo title casing

d2eb8df

domfarolino approved these changes Nov 29, 2024

View reviewed changes

source Show resolved Hide resolved

source Show resolved Hide resolved

remove accidental ofs

0a57503

annevk reviewed Dec 4, 2024

View reviewed changes

source Show resolved Hide resolved

source Outdated Show resolved Hide resolved

keithamus and others added 5 commits December 4, 2024 09:15

rephrase "corresponding to" state values

d02a649

s/, return/, then return

9aa7109

line wrapping pass

463df24

address various issues

c37596b

CI found another place that got improved

35849e7

annevk added addition/proposal New features or enhancements do not merge yet Pull request must not be merged per rationale in comment needs tests Moving the issue forward requires someone to write tests labels Dec 4, 2024

keithamus mentioned this pull request Dec 6, 2024

Lift restriction on buttons with implicit type=submit and command/commandfor being no-op #10832

Open

fix implicit submit/commandfor button logic

d27d514

chromium-wpt-export-bot mentioned this pull request Dec 9, 2024

Re-design logic for commandfor form-owner combinations web-platform-tests/wpt#49594

Merged

jamesnw mentioned this pull request Dec 10, 2024

Add Invoker Commands API web-platform-dx/web-features#2411

Open

keithamus mentioned this pull request Dec 11, 2024

Make <dialog> usable without JS (for form confirmation) #10851

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add commandfor & command attributes to HTMLButtonElement #9841

Add commandfor & command attributes to HTMLButtonElement #9841

keithamus commented Oct 8, 2023 •

edited by pr-preview bot

Loading

scottaohara commented Oct 18, 2023 •

edited

Loading

This comment was marked as outdated.

lukewarlow commented Nov 4, 2023

domenic commented Nov 5, 2023

keithamus commented Nov 5, 2023

domenic commented Nov 5, 2023 •

edited

Loading

lukewarlow commented Dec 1, 2023

lukewarlow commented Dec 1, 2023

mfreed7 commented Jan 17, 2024

keithamus commented Jan 17, 2024

mfreed7 commented Jan 17, 2024

annevk commented Dec 4, 2024

annevk left a comment

keithamus commented Dec 4, 2024

Add commandfor & command attributes to HTMLButtonElement #9841

Are you sure you want to change the base?

Add commandfor & command attributes to HTMLButtonElement #9841

Conversation

keithamus commented Oct 8, 2023 • edited by pr-preview bot Loading

scottaohara commented Oct 18, 2023 • edited Loading

This comment was marked as outdated.

lukewarlow commented Nov 4, 2023

domenic commented Nov 5, 2023

keithamus commented Nov 5, 2023

domenic commented Nov 5, 2023 • edited Loading

lukewarlow commented Dec 1, 2023

lukewarlow commented Dec 1, 2023

mfreed7 commented Jan 17, 2024

keithamus commented Jan 17, 2024

mfreed7 commented Jan 17, 2024

annevk commented Dec 4, 2024

annevk left a comment

Choose a reason for hiding this comment

keithamus commented Dec 4, 2024

keithamus commented Oct 8, 2023 •

edited by pr-preview bot

Loading

scottaohara commented Oct 18, 2023 •

edited

Loading

domenic commented Nov 5, 2023 •

edited

Loading