[Platform-provided behaviors for CE] Address feedback, add alternative to main proposal

[anaskim]

Updates

Main explainer

• User-facing problem: Promote the form-control pseudo-class set and the native focusability algorithm into the reimplementation bullet.
• User research: Reframe the closing paragraph around <button type="submit"> as a single-element conformance target that exercises every part of the framework.
• Dynamic behaviors: Add set / state / participation at the start of the section.
• attachInternals() lifecycle: attachInternals() can be called from the constructor, connectedCallback, or attributeChangedCallback, depending on whether attributes are set before or after construction.
• Alt API design 3: Open questions resolved; the recomputation table collapsed into a single sentence pair.
• Behavior composition and conflict resolution: Moved out of the main proposal area into Future work (only HTMLSubmitButtonBehavior ships initially; composition becomes relevant once additional behaviors land).
• HTMLSubmitButtonBehavior properties: Added title with a note that it surfaces through the user agent's default tooltip UI. Removed the attributeChangedCallback example.
• Trimming and fixes: Cut duplicate examples in Accessing behavior state, API design, Conflicting behaviors, and Other considerations. Folded "Why start with form submission?" into the Introduction. Converted the Behavior lifecycle table to a paragraph. Fixed an invalid optional-chaining assignment in the opening Proposed approach example.

New alternative

New file: PlatformProvidedBehaviors/htmlbuttonbehavior-with-type-attribute.md. Side document exploring an alternative:

1. Collapses the three button modes (submit, reset, generic-button) into a single HTMLButtonBehavior whose type property mirrors the type attribute of native <button> and toggles the active mode at runtime.
2. Declares behaviors via a static behaviors class property. The platform instantiates each declared behavior at element creation; authors look up the instance through internals.behaviors.get(HTMLButtonBehavior).

[dandclark]

Suggested change

	Calling `attachInternals()` with behaviors adds each behavior's event handlers and the default ARIA role is applied. Disconnecting the element from the DOM leaves event handlers attached but suspends them, while behavior state (`formAction`, `disabled`, etc.) is preserved. Reconnecting reactivates event handling against the preserved state.
	Calling `attachInternals()` with behaviors adds each behavior's event handlers and the ARIA associated with that behavior is applied. Disconnecting the element from the DOM leaves event handlers attached but suspends them, while behavior state (`formAction`, `disabled`, etc.) is preserved. Reconnecting reactivates event handling against the preserved state.

The suggested change tries to clarify what "default role" means here.

[gregwhitworth]

Non-blocking comments primarily but I am curious about the other proposal and which one we ultimately want to put forward so keeping this at a "comment" phase so we can debate if necessary

[gregwhitworth]

I'm curious what others think but I don't want to bring this up in this proposal. Let that proposal stand on its own once we know developers need it and this aspect has landed.

[dandclark]

It's a little unclear what HTMLButtonBehavior is in this version. It seems like it's not instantiable here, right? And it maybe doesn't have any properties of its own, it's more of a special marker type?

Also worth pointing out that we could do more of a hybrid approach where we do everything the way it is in the approach in the main explainer, but instead of HTMLSubmitButtonBehavior we have HTMLButtonBehavior with a dynamic type that can support button/submit/reset.

[dandclark]

Reading further, I guess HTMLButtonBehavior is the class of the object that will get added to the behaviors array? So it'll be like this?

class CustomButton extends HTMLElement {
  static formAssociated = true;
  static behaviors = [HTMLButtonBehavior];

  #internals;
  constructor() {
    super();
    const buttonBehavior = this.#internals.behaviors.get(HTMLButtonBehavior);
    buttonBehavior instanceof HTMLButtonBehavior; // true
  }
}

new HTMLButtonBehavior(); // is this still allowed?