Button Activation Behaviors as mixins

It seems like mixins fit better for this feature semantically:

• the engine doesn't have to do a check (f.e. a switch case for this.constructor.buttonActivationBehaviors and other similar future behaviors) for every single element even when most of them don't have these static fields in their constructor
• every element having the features exposed on them, but erroring when not applicable, is a little odd.
• type systems need to make an already big bag of HTMLElement members bigger, despite them being unused if not enabled.

With mixins, per-instance conditional checking is avoided, properties are cleanly and semantically provided by a mixin, type definitions are cleanly separated (f.e. in TypeScript), and elements don't become a bigger bag of irrelevant unused properties/methods.

For example, instead of the following pattern (which means either TypeScript has to provide types for all possible static properties on the super class, or none at all which is unhelpful for people in their IDE)

class MyButton extends HTMLElement {
  static buttonActivationBehaviors = true
}

customElements.define('my-btn', MyButton)

the following pattern work well semantically for the given reasons (and type awareness for both inherited static and inherited instance members would be applicable only on specific elements that use the mixins):

class MyButton extends ButtonActivationBehaviors(HTMLElement) {}

customElements.define('my-btn', MyButton)

With mixins, features that should exist for an element are self contained in the applied mixins, rather than the existing base class being less clear both at runtime and during type checking and IDE intellisense.

Thoughts?

Start by reviewing the ButtonActivationBehaviors proposal, including the HTMLElement inheritance and customElements.define examples, and compare the static-field approach with the suggested mixin pattern. The issue requests design feedback and does not identify files, tests, or an implementation-ready definition of done.