Add platform-provided behaviors for custom elements & submit behavior

[anaskim]

#12150

This change introduces platform-provided behaviors, a mechanism that allows autonomous custom elements to adopt built-in HTML element capabilities via attachInternals(). The initial element behavior is HTMLSubmitButtonBehavior, which gives a custom element submit button semantics including form submission, activation, focusability, and an implicit ARIA role.

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

• At least two implementers are interested (and none opposed):
  • Chromium: Chrome Status entry & implementation bug
  • Webkit standards position
  • Mozilla standards position
• Tests are written and can be reviewed and commented upon at:
  • https://wpt.fyi/results/custom-elements/form-associated?label=master&label=experimental&aligned&q=form-associated%20is%3Atentative
  • https://wpt.fyi/results/custom-elements?label=master&label=experimental&aligned&q=is%3Atentative
  • TODO: PR to make them non-tentative.
• Implementation bugs are filed:
  • Chromium: https://issues.chromium.org/issues/486928684
  • Gecko: …
  • WebKit: …
• Corresponding HTML AAM & ARIA in HTML issues & PRs:
• MDN issue is filed: …
• The top of this comment includes a clear commit message to use.

(See WHATWG Working Mode: Changes for more details.)

---

/custom-elements.html ( diff )
/dom.html ( diff )
/form-control-infrastructure.html ( diff )
/forms.html ( diff )
/index.html ( diff )
/interaction.html ( diff )
/semantics-other.html ( diff )

[keithamus]

I have done an initial pass, just glossing over this. Things look generally good (though I will look a lot closer later this week). One question that stands out from a first pass: we use instanceof checks to check a behaviour, which prompts me to check subclasses. The behaviour is a little surprising... So for example in Chrome today:

class Foo extends HTMLSubmitButtonBehavior { };
class Bar extends HTMLSubmitButtonBehavior { };
class MyEl extends HTMLElement { 
  constructor() {
    super();
    this.foo = new Foo();
    this.bar = new Bar();
    this.attachInternals({ behaviors: [this.foo, this.bar] });
  }
}
customElements.define('my-el', MyEl);
document.createElement('my-el');

This gives me an error of Uncaught TypeError: Failed to execute 'attachInternals' on 'HTMLElement': Only one instance of HTMLSubmitButtonBehavior is allowed per element. which seems right, but it's a confusing message as MyEl only attached Foo and Bar.

My assumption would have been we prevent users from extending behaviours; there are a lot of questions about what inheriting means, especially for a native behaviour. Might be worth some investigation. I think the plausible answers are "prevent inheritance" or "offer a lot more detail on what's possible/use cases for inheritance".

[anaskim]

I have done an initial pass, just glossing over this. Things look generally good (though I will look a lot closer later this week). One question that stands out from a first pass: we use instanceof checks to check a behaviour, which prompts me to check subclasses. The behaviour is a little surprising... So for example in Chrome today:

class Foo extends HTMLSubmitButtonBehavior { };
class Bar extends HTMLSubmitButtonBehavior { };
class MyEl extends HTMLElement { 
  constructor() {
    super();
    this.foo = new Foo();
    this.bar = new Bar();
    this.attachInternals({ behaviors: [this.foo, this.bar] });
  }
}
customElements.define('my-el', MyEl);
document.createElement('my-el');

This gives me an error of Uncaught TypeError: Failed to execute 'attachInternals' on 'HTMLElement': Only one instance of HTMLSubmitButtonBehavior is allowed per element. which seems right, but it's a confusing message as MyEl only attached Foo and Bar.

My assumption would have been we prevent users from extending behaviours; there are a lot of questions about what inheriting means, especially for a native behaviour. Might be worth some investigation. I think the plausible answers are "prevent inheritance" or "offer a lot more detail on what's possible/use cases for inheritance".

Thanks for taking a look, @keithamus! My inclination is to say that subclassing platform-provided behaviors like HTMLSubmitButtonBehavior should not be allowed. The instanceof-based duplicate check makes subclass interactions confusing, as your example shows, and there isn’t a clear semantic for what customizing a native/platform-provided behavior through inheritance should mean.

I’ve updated the spec text so HTMLSubmitButtonBehavior() throws a TypeError when constructed through a subclass,
and added a short note explaining that platform-provided behaviors are not designed to be subclassed. Let me know if you think this should be captured differently, but I think preventing subclassing is the cleaner option for this proposal.