standards-positions icon indicating copy to clipboard operation
standards-positions copied to clipboard

Button Activation Behaviors

Open anaskim opened this issue 7 months ago • 2 comments

WebKittens

@annevk

Title of the proposal

Button Activation Behaviors

URL to the spec

https://github.com/whatwg/html/issues/11061 (no spec PR yet)

URL to the spec's repository

https://github.com/whatwg/html

Issue Tracker URL

No response

Explainer URL

https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/ElementInternalsType/explainer.md

TAG Design Review URL

TBD

Mozilla standards-positions issue URL

https://github.com/mozilla/standards-positions/issues/1250

WebKit Bugzilla URL

No response

Radar URL

No response

Description

This proposal introduces a way for custom elements to opt into specific button activation behaviors through a static property declaration. By building on the established pattern of form-associated custom elements, this approach provides a familiar developer experience while ensuring cross-browser compatibility and proper integration with platform features like the Invoker Commands API.

Currently, web developers face challenges when trying to implement custom buttons as popover invokers while providing unique styles and additional functionality (as discussed here). The existing customized built-in approach using extends and is provides native button functionality but lacks full cross-browser support. As a result, developers are forced to manually reimplement button behaviors from scratch, leading to inconsistent implementations, accessibility issues, and development overhead.

anaskim avatar Jun 13 '25 19:06 anaskim

Colleagues and I support the general idea here, but we'll wait with a formal position until the proposal is more concrete. One thing that strikes me as a little odd is that it creates a new layer below ElementInternals for ARIA state. I wonder if instead it should initialize ElementInternals ARIA state, so that we don't add another layer of inheritance.

annevk avatar Jun 23 '25 14:06 annevk

Hi @annevk! Thank you for all your feedback.

I wonder if instead it should initialize ElementInternals ARIA state, so that we don't add another layer of inheritance.

The reason why we don't set a default value in elementInternals.role is to sync the behavior of element.role. We can create a separate issue to discuss further.

We've updated this issue and the explainer to reflect our current proposal, which can be found here. It includes the following changes:

  1. Expose the activation behaviors only: static buttonActivationBehaviors = true.
  2. Expose only command/commandFor initially, with submit/reset as fast follows.
  3. ARIA behaviors (focusability, role=button) will be automatically included based on the ARIA WG’s overwhelming consensus.
  4. Form association will NOT be automatically included.

We’d appreciate your thoughts on this update.

anaskim avatar Oct 20 '25 21:10 anaskim