Add platform-provided mixins explainer

[anaskim]

V1 includes:

• Rewording on interoperability.
• Adds examples on current workarounds used by frameworks.
• Adds goal to clarify the general and specific objectives of the proposal.
• "behavior" -> "mixin", to avoid confusion with "behaviour" spelling.
• Simplifies to add mixins to attachInternals() and avoid dynamic changes at runtime.
• Adds mixins property to ElementInternals to query behaviors.
• Removed "Open questions" section and expanded "Future Work" section with a "collision handling" note and 2 more proposed mixins (input and table behaviors).
• Updated "Accessibility, Security, and Privacy Considerations" section.
• Updated acknowledgements.

[KurtCattiSchmidt]

Another pro to this approach is that it allows for child classes to easily extend from mixins. e.g.

class CustomSubmitButton extends HTMLSubmitButtonMixin(HTMLElement) { ... }
class ExtraCustomSubmitButton extends CustomSubmitButton {...}

Is this possible with the current mixin proposal?

[anaskim]

Yes, we talked about in the meeting about child classes inheriting ElementInternals. I tested it and child classes do inherit the instance and can modify it. With the proposed approach we could have:

class ParentElement extends HTMLElement {
  #internals;

  constructor() {
    super();
    this.#internals = this.attachInternals();
    // ...
    this._internals = this.attachInternals({ mixins });
  }

  _getInternals() {
    return this.#internals;
  }
}

class ChildElement extends ParentElement {
  constructor() {
    super();
    const internals = this._getInternals();
    internals.role = 'checkbox'; 
    const isSubmit = this._internals.mixins.includes(HTMLSubmitButtonMixin);
    if (isSubmit) {
      // ...
    }
  }
}

[KurtCattiSchmidt]

Does it make sense to list "Extend Markup Like Customizable Select"? Or is that too different of a problem? The dealbreaking con with this approach is that it won't work for all types (or any types beyond select?).

https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Forms/Customizable_select

[anaskim]

Yes, added it as an alternative. PTAL.

[mhochk]

To complete the picture of what this approach would look like as a framework, I recommend adding an additional example that shows what inheritance and multiple-mixins would look like. Preface it with a disclaimer that the initial proposal is only for a single mixin, but that this is what the future might look like.

In particular, I think it will be worthwhile to show:

• How a parent class and sub-class can both contribute to what mixins get applied (since attachInternals may only be called once, I believe it would require custom coordination)
• How a class can determine what mixins are "winning" when the mixins array has multiple values (since just doing an includes check won't tell you what aspects of that mixin are being overriden by another mixin)

A possible scenario for this could be a class that wants HTMLSubmitButtonMixin, and then a sub-class that wants to retain the :default/enter behaviors of that (as well as the custom html/style), but wants to also add HTMLResetButtonMixin to reset the form instead of submitting it.

[anaskim]

Added it below the Future work section. PTAL.

[mhochk]

Looks ready for wider-web discussion to me 👍