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]

NIT: The name/title is typically Title Cased

Suggested change

	name: Platform-provided mixins
	about: new issue
	title: "[Platform-provided mixins] <TITLE HERE>"
	name: Platform-Provided Mixins
	about: new issue
	title: "[Platform-Provided Mixins] <TITLE HERE>"

[mhochk]

Might be worth tossing in that it would also be less performant and 100% broken if JavaScript is disabled.

[mhochk]

NIT: This looks to only have ~50 direct comments. I'm guessing you're including all the comments from all the other Issues that link to this Issue as well?

I recommend just not including the call-out about how many comments it has, as it seems to imply that this single Issue covers a drastically larger discussion than the others.

Suggested change

	- [WICG/webcomponents#814](https://github.com/WICG/webcomponents/issues/814) - Form submission from custom elements (400+ comments)
	- [WICG/webcomponents#814](https://github.com/WICG/webcomponents/issues/814) - Form submission from custom elements

[mhochk]

I don't think using "behaviors" would be a problem on account of spelling. The web standards space has already aligned on "behaviors" being the spelling for things like scroll-behavior and overscroll-behavior, similar to its use of "color" throughout (rather than "colour").

[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.

[mhochk]

Another con would be that since the composition doesn't have an order/sequence to it, the web developer would not be able to specify a desired "winner" when using multiple behaviors that happen to impact a shared value or scenario.