Button Activation Behaviors
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.
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.
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:
- Expose the activation behaviors only:
static buttonActivationBehaviors = true. - Expose only
command/commandForinitially, withsubmit/resetas fast follows. - ARIA behaviors (focusability,
role=button) will be automatically included based on the ARIA WG’s overwhelming consensus. - Form association will NOT be automatically included.
We’d appreciate your thoughts on this update.