From 92bcb547015eb9773953a8d8de250f3eca553b1d Mon Sep 17 00:00:00 2001
From: Ana Sollano Kim <ansollan@microsoft.com>
Date: Mon, 6 Jul 2026 12:45:46 -0700
Subject: [PATCH 1/5] Add HTMLButtonBehavior with type attribute alternative

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---
 .../htmlbuttonbehavior-with-type-attribute.md | 394 ++++++++++++++++++
 1 file changed, 394 insertions(+)
 create mode 100644 PlatformProvidedBehaviors/htmlbuttonbehavior-with-type-attribute.md

diff --git a/PlatformProvidedBehaviors/htmlbuttonbehavior-with-type-attribute.md b/PlatformProvidedBehaviors/htmlbuttonbehavior-with-type-attribute.md
new file mode 100644
index 000000000..2420342b2
--- /dev/null
+++ b/PlatformProvidedBehaviors/htmlbuttonbehavior-with-type-attribute.md
@@ -0,0 +1,394 @@
+# Alternative: HTMLButtonBehavior
+
+This document explores an alternative direction for [platform-provided behaviors](explainer.md). This alternative differs in two ways:
+
+1. It collapses the three button modes into a single `HTMLButtonBehavior` whose `type` property mirrors the `type` attribute of native `<button>`. The behavior's `type` toggles which button mode the host participates in. Everything else (focusability, role, pseudo-classes, the activation path) is constant across types.
+2. It declares behaviors via a `static behaviors` class property, letting the platform own behavior instantiation. Authors access the platform-created instances through a new `behaviors` collection on `ElementInternals`.
+
+Four things motivate this alternative:
+
+1. Modeling the button types as three separate behaviors duplicates most of the surface to express activation differences.
+2. Web authors who want a single custom element class that can switch between submit, reset, and generic-button at runtime also want one element with one mutable property. A single `HTMLButtonBehavior` with a mutable `type` avoids having to define what happens when two button-shaped behaviors are attached at once and one is toggled off.
+3. It matches native `<button>` and frameworks also use this shape.
+4. The platform owns instantiation; authors look up state through `ElementInternals`.
+
+## Proposed approach
+
+A platform-provided behavior is a set of methods, values, and platform-protocol hooks that a custom element can participate in, which today are reserved to native HTML elements. This alternative introduces a `behaviors` static class property that declares which behaviors the platform attaches to instances of the class.
+
+The platform reads `static behaviors` at `customElements.define()` time and stores it on the custom element definition, the same way it reads `static formAssociated`. When an element is created (`new`, parser upgrade, or `customElements.upgrade()`), the platform instantiates one of each declared behavior per host and associates them with the element. This mirrors how a form-associated custom element participates in form submission and form-related lifecycle callbacks.
+
+`attachInternals()` is the author's access route to those already-existing instances, exposed through a new `behaviors` collection on `ElementInternals`. The set of behaviors attached to a host is fixed at the class declaration; the behavior instances themselves remain mutable post-attachment.
+
+```javascript
+class CustomButton extends HTMLElement {
+  static formAssociated = true;
+  // Declare which behaviors the platform attaches to each instance.
+  static behaviors = [HTMLButtonBehavior];
+
+  #internals;
+  constructor() {
+    super();
+    // attachInternals() is the access route to the platform-created behaviors.
+    this.#internals = this.attachInternals();
+
+    // Access the behavior state directly.
+    const buttonBehavior = this.#internals.behaviors.get(HTMLButtonBehavior);
+
+    // Modify the behavior's properties.
+    buttonBehavior.formAction = '/custom';
+    buttonBehavior.type = 'reset';
+  }
+}
+```
+
+In this model authors never construct behaviors. `new HTMLButtonBehavior()` throws an `"Illegal constructor"` `TypeError`, the same as `ElementInternals`, because a free-standing instance would have no host to act on. The instance is obtained only through `internals.behaviors.get(HTMLButtonBehavior)` after `attachInternals()`.
+
+Each behavior names the specific platform logic it engages:
+
+- Event handling and activation.
+- ARIA defaults (implicit role and ARIA properties).
+- Focusability
+- CSS pseudo-classes.
+- Configurable data and state owned by the behavior.
+- Platform protocol hooks.
+
+### Behavior categories and composition
+
+Behaviors are organized into a set of categories, expressed as abstract base classes.
+
+```mermaid
+classDiagram
+    class ElementBehavior
+    class ActivationBehavior {
+        <<abstract>>
+        +activationBehavior(event)
+        +legacyPreActivationBehavior(event)
+        +legacyCanceledActivationBehavior(event)
+    }
+    class EmbeddedContentBehavior {
+        <<abstract>>
+    }
+    class HTMLButtonBehavior
+    class HTMLLabelBehavior
+    class HTMLRadioGroupBehavior
+    class HTMLCheckboxBehavior
+    class HTMLImageBehavior
+    ElementBehavior <|-- ActivationBehavior
+    ElementBehavior <|-- EmbeddedContentBehavior
+    ActivationBehavior <|-- HTMLButtonBehavior
+    ActivationBehavior <|-- HTMLLabelBehavior
+    ActivationBehavior <|-- HTMLRadioGroupBehavior
+    ActivationBehavior <|-- HTMLCheckboxBehavior
+    EmbeddedContentBehavior <|-- HTMLImageBehavior
+```
+
+`ActivationBehavior` and `EmbeddedContentBehavior` are abstract category bases; the concrete leaves (`HTMLButtonBehavior`, `HTMLLabelBehavior`, `HTMLRadioGroupBehavior`, `HTMLCheckboxBehavior`, `HTMLImageBehavior`) are what an author attaches.
+
+An element attaches at most one behavior per category. Two behaviors in the same category are mutually exclusive, and attaching both throws a `TypeError`:
+
+```javascript
+static behaviors = [HTMLButtonBehavior, HTMLLabelBehavior]; // throws!
+// TypeError: an element can have at most one ActivationBehavior;
+// HTMLButtonBehavior and HTMLLabelBehavior cannot be combined.
+```
+
+Behaviors in different categories compose. Combining an `HTMLButtonBehavior` (activation) with an `HTMLImageBehavior` (embedded content) produces a submit button that renders as an image, similar to [`<input type=image>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/image):
+
+```javascript
+class ImageButton extends HTMLElement {
+  static formAssociated = true;
+  static observedAttributes = ['src', 'alt'];
+  static behaviors = [HTMLButtonBehavior, HTMLImageBehavior];
+
+  #internals;
+  #image;
+
+  constructor() {
+    super();
+    this.#internals = this.attachInternals();
+    // HTMLButtonBehavior defaults to type 'submit'.
+    this.#image = this.#internals.behaviors.get(HTMLImageBehavior);
+  }
+
+  attributeChangedCallback(name, _old, value) {
+    if (name === 'src') {
+      this.#image.src = value;
+    }
+    if (name === 'alt') {
+      this.#image.alt = value;
+    }
+  }
+}
+customElements.define('image-button', ImageButton);
+```
+
+```html
+<form action="/search">
+  <image-button src="/go.png" alt="Search"></image-button>
+</form>
+```
+
+On activation the host submits the form (from `HTMLButtonBehavior`) while rendering the image and exposing its `alt` text as the accessible name (from `HTMLImageBehavior`). The two behaviors are in different categories, so the platform allows the combination. Because the category is the base class, the platform decides compatibility with a membership test. Adding a new behavior only requires placing it under the right base; it does not require enumerating its compatibility with every existing behavior.
+
+#### `ActivationBehavior`
+
+`ActivationBehavior` corresponds to the DOM standard's [activation behavior](https://dom.spec.whatwg.org/#eventtarget-activation-behavior): the algorithm an `EventTarget` runs when a `click` is dispatched to it and not canceled. The DOM standard pairs it with two optional hooks, [legacy-pre-activation behavior](https://dom.spec.whatwg.org/#eventtarget-legacy-pre-activation-behavior) and [legacy-canceled-activation behavior](https://dom.spec.whatwg.org/#eventtarget-legacy-canceled-activation-behavior), which native checkbox and radio use to set checkedness before listeners run and restore it if the event is canceled.
+
+`ActivationBehavior` provides:
+
+- Participation in the activation dispatch path (click, keyboard activation, and `element.click()`), honoring `preventDefault()` and `stopPropagation()`.
+- The `legacy-pre-activation behavior` and `legacy-canceled-activation behavior` hooks (no-ops unless overridden).
+
+Each concrete behavior supplies the rest:
+
+- What the element does when activated (the activation algorithm).
+- Its implicit ARIA role default.
+- Its focusability default.
+- Its keyboard-activation specifics.
+- Its own state and the protocol surface it exposes.
+
+Mapping a few native patterns onto categories helps validate the model:
+
+| Native pattern | Behavior | Category | Notes |
+|---|---|---|---|
+| `<button>` | `HTMLButtonBehavior` | activation | submit/reset/button via `type`; invoker surface; form participation. |
+| `<label>` | `HTMLLabelBehavior` | activation | `for`-attribute association and focus delegation, activation delegates a click to the labeled control, no implicit role, not focusable. |
+| `<input type=radio>` | `HTMLRadioGroupBehavior` | activation | `name`-based mutual exclusion; needs the `legacy-pre-activation`/`legacy-canceled-activation` hooks for the check-then-restore dance. This is the concrete reason the base exposes those hooks. |
+| `<input type=checkbox>` | `HTMLCheckboxBehavior` | activation | An independent on/off toggle, using the same `legacy-pre-activation`/`legacy-canceled-activation` hooks. |
+
+Of these, `HTMLButtonBehavior`, `HTMLLabelBehavior`, and `HTMLRadioGroupBehavior` are the near-term candidates for future work.
+
+The embedded-content category corresponds to the HTML spec's [embedded content](https://html.spec.whatwg.org/multipage/dom.html#embedded-content-2).
+
+### HTMLButtonBehavior
+
+This alternative introduces `HTMLButtonBehavior`, a behavior in the activation category (`class HTMLButtonBehavior extends ActivationBehavior`) that mirrors native `<button>`.
+
+- The behavior has a `type` property (`'submit'` (default), `'reset'`, or `'button'`) that selects the active button mode. The `type` is mutable for the life of the behavior.
+- User activation (click, Enter, Space, implicit submission) reaches the behavior through the same DOM event-dispatch path as native elements.
+- The behavior provides a default implicit `role="button"`. Authors can override the role through `internals.role`.
+- The custom element with HTMLButtonBehavior participates in sequential focus navigation, with `tabindex` and disabled state following established rules.
+- The same logic that toggles `:default`, `:disabled`/`:enabled`, `:focus`, and `:focus-visible` on native elements applies to the behavior's host. The `:default` pseudo-class only matches when `type === 'submit'` and the host is the form's default submit button.
+- Mirrored `HTMLButtonElement` properties are available on the behavior instance. They are configurable per-element and mutable for the life of the behavior.
+- Form ownership applies whenever `type` is `'submit'` or `'reset'`. Activation behavior depends on `type`: `'submit'` triggers form submission and implicit submission; `'reset'` triggers form reset; `'button'` does generic activation.
+
+`HTMLButtonBehavior` builds on top of [form-associated custom elements (FACEs)](https://html.spec.whatwg.org/multipage/custom-elements.html#form-associated-custom-elements). The custom element still has to opt in to form association with `static formAssociated = true` for submission to actually fire when `type` is `'submit'` or `'reset'`. Without it, `behavior.form` is always `null` and activation is a no-op even when the element is inside a form. This is a divergence from native `<button>`, which submits its form without any explicit opt-in.
+
+| Scenario | Behavior |
+|----------|----------|
+| Form-associated element inside a form, `type === 'submit'` | Activation triggers submission, participates in implicit submission, matches `:default`. Invoker attributes on the host (`commandfor`, `popovertarget`) are ignored, matching native `<button type="submit">`. |
+| Form-associated element inside a form, `type === 'reset'` | Activation triggers form reset. Invoker attributes on the host are ignored, matching native `<button type="reset">`. |
+| Form-associated element inside a form, `type === 'button'` | Activation is a no-op for form behavior. Invoker attributes on the host (`commandfor`, `popovertarget`) fire as usual. |
+| Form-associated element outside a form, or non-form-associated element | `behavior.form` is `null`. With no form owner, the host behaves like a native `<button>` without a form owner for all `type` values: there is no form to submit or reset, but invoker attributes on the host (`commandfor`, `popovertarget`) fire as usual and the element still gets `role="button"` and implicit focusability. |
+
+### Behaviors are not opaque tokens
+
+A recurring concern about consolidating form-control semantics into an opt-in is that web authors will not be able to figure out what a given opt-in actually does. This proposal addresses that concern:
+
+- Each element behavior maps to a single native pattern (e.g., `HTMLButtonBehavior` provides exactly the semantics of `<button>`). Future element behaviors will need to follow the same naming convention.
+- Each behavior is specified in terms of existing HTML algorithms. The behavior is the union of those algorithms, applied to a custom element.
+- Web authors can override individual defaults. This already works today for role: `internals.role` overrides a behavior's default role without replacing the behavior. The same layering pattern can extend to other defaults (focusability, keyboard activation, and similar) if and when future proposals add the corresponding primitives on `ElementInternals`.
+
+### Accessing behavior state
+
+Each behavior exposes properties from its corresponding native element. Behaviors can be accessed via `internals.behaviors`. For `HTMLButtonBehavior`, the following properties are available (mirroring [`HTMLButtonElement`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLButtonElement)):
+
+**Properties:**
+- `type` - selects the active button mode (`'submit'`, `'reset'`, or `'button'`); defaults to `'submit'`.
+- `disabled` - read-only. Reflects whether the element is disabled, which is determined by the standard form-control mechanism (the `disabled` attribute or a `<fieldset disabled>` ancestor, [spec](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#attr-fe-disabled)) and surfaced through `ElementInternals`. This proposal does not add a separately settable per-behavior disabled state.
+- `form` - read-only, delegates to `ElementInternals.form`. Form ownership only affects activation when `type` is `'submit'` or `'reset'`.
+- `name`, `value` - submitter name and value. Read on submission (`type === 'submit'`).
+- `formAction`, `formEnctype`, `formMethod`, `formNoValidate`, `formTarget` - submission overrides. Read on submission (`type === 'submit'`).
+- `labels` - read-only, delegates to `ElementInternals.labels`.
+
+*Note: `HTMLButtonElement` adds the properties listed above on top of `HTMLElement`. Custom elements already inherit the global `HTMLElement` IDL surface (`title`, `tabIndex`, `hidden`, etc.). Web authors can use these properties on the host as they would on any element.*
+
+To expose these properties to external code, authors define getters and setters on the host that delegate to the behavior. See [Use case: Design system button](#use-case-design-system-button) for a complete worked example.
+
+### Behavior lifecycle
+
+| Event | What happens |
+|-------|--------------|
+| Element creation (`new`, parser upgrade, or `customElements.upgrade()`) | The platform instantiates each declared behavior with its defined defaults. The behavior's `type` selects the initial active button mode (`'submit'` by default). Role, focusability, and pseudo-class participation are active from this point. |
+| `attachInternals()` | `internals.behaviors` is populated with the already-existing behavior instances. Authors now have read/write access through `internals.behaviors.get(ElementBehavior)`. |
+| Host connected | Form association runs if `formAssociated = true`. The behavior's `form` is resolved. |
+| `behavior.type` set to a new value | Form ownership, role, focusability, and pseudo-class state are recomputed. See [Mutating the `type` property](#mutating-the-type-property). |
+| Host disconnected | Form association detaches. The behavior remains attached for when the host re-connects. |
+
+### Mutating the `type` property
+
+Setting `behavior.type` to a new value toggles the activation path and which pseudo-classes match.
+
+```javascript
+const buttonBehavior = this.#internals.behaviors.get(HTMLButtonBehavior);
+buttonBehavior.type = 'reset'; // Was 'submit', now 'reset'.
+```
+
+Each subsystem affected by `type` is recomputed through the same paths the platform already runs for native `<button>` when its `type` attribute changes.
+
+| Subsystem | Recompute when `behavior.type` is set |
+|-----------|--------------------------------------|
+| Form ownership | Re-association runs. `type === 'button'` detaches the behavior from form ownership; `type === 'submit'` or `'reset'` attaches it. |
+| Activation behavior | The next activation runs against the new `type`. |
+| `:default` match | Re-evaluated. Only matches when `type === 'submit'` and the host is the form's default submit button. |
+| Implicit ARIA role | Unchanged. The role is `"button"` for all `type` values, so no recompute is needed. |
+| Focusability | Unchanged. Focusability is the same for all `type` values. |
+
+Setting `behavior.type` to an unknown string does not throw. The behavior coerces the value to the default state (`'submit'`), and the getter returns the canonical keyword for the active state. This matches the [Auto state](https://html.spec.whatwg.org/multipage/form-elements.html#attr-button-type-auto-state) that `<button>`'s `type` content attribute uses as the missing-value and invalid-value default.
+
+Changing `behavior.type` between events of a single interaction (for example, between `mousedown` and `mouseup`, or between `keydown` and `keyup` on a key activation) queues the change. The change applies at end-of-interaction, between event tasks. This mirrors how the platform already handles `type` mutations on a native `<button>` during click dispatch.
+
+### API design
+
+Authors declare behaviors via a static class property; the platform creates and exposes the instances:
+
+- `static behaviors` is an array of behavior classes (not instances).
+- The platform instantiates each declared behavior with its defined defaults at element creation.
+- `ElementInternals.behaviors` is a read-only, Map-like collection keyed by behavior class. `internals.behaviors.get(HTMLButtonBehavior)` returns the instance for this host. Entries can't be added or removed at runtime.
+- Web authors hold references to behavior instances by looking them up through `internals.behaviors` once and caching the reference.
+
+#### Classes vs a string-based API
+
+Behaviors are class references, not string tokens. An earlier proposal, [`elementInternals.type`](https://github.com/whatwg/html/issues/11061), collected consistent feedback that a string opt-in is the wrong shape for this problem. That feedback motivates the class-based design used here.
+
+- A misspelled token has no good failure mode. [As noted in the discussion](https://github.com/whatwg/html/issues/11061#issuecomment-3146290495), `static activationBehavior = 'buton'` "likely [...] can't throw," so the typo silently does nothing. A class reference is resolved by the JavaScript engine, so a misspelled `HTMLButtnBehavior` is a `ReferenceError` at parse time instead of a no-op.
+- String tokens are not discoverable. The [same comment](https://github.com/whatwg/html/issues/11061#issuecomment-3146290495) adds that string tokens are "not super discoverable [...] there is no additional API surface to discover." A behavior class carries its own surface (properties, methods, and an `instanceof` relationship) that authors and tooling can inspect. See [Behaviors are not opaque tokens](#behaviors-are-not-opaque-tokens).
+
+#### One `behaviors` array vs per-category slots
+
+Even with classes instead of strings, the declaration could be split into one named opt-in per category. [Issue #1353](https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/1353) proposes a `static activationBehavior` next to a `static replacedContent`, each set to a cluster keyword, so conflicts resolve at the WebIDL level: one slot per category.
+
+```javascript
+// Per-category string clusters (issue #1353)
+static activationBehavior = 'button';
+static replacedContent = 'image';
+```
+
+The keywords carry the [same problems](#classes-vs-a-string-based-api). Substituting classes keeps the per-slot shape while repeating what the class already encodes:
+
+```javascript
+// Per-category slots, with classes
+static activationBehavior = HTMLButtonBehavior;
+static replacedContent = HTMLImageBehavior;
+
+// Or one object keyed by category
+static behaviors = {
+  activationBehavior: HTMLButtonBehavior,
+  replacedContent: HTMLImageBehavior,
+};
+```
+
+`HTMLButtonBehavior extends ActivationBehavior`, so its category is intrinsic. Naming the slot (`activationBehavior:`) restates that. It also forces the author to know the right key for every behavior, and a wrong key (`replacedContent: HTMLButtonBehavior`) becomes a new failure mode. A single flat array avoids all of it:
+
+```javascript
+static behaviors = [HTMLButtonBehavior, HTMLImageBehavior];
+```
+
+The platform reads each behavior's category from its base class, so it enforces one behavior per category on its own (see [Behavior categories and composition](#behavior-categories-and-composition)). The declaration stays short as categories are added, and each behavior is named once.
+
+### Feature detection
+
+Web authors can detect whether behaviors are supported by checking for the existence of behavior classes on the global scope:
+
+```javascript
+if (typeof HTMLButtonBehavior !== 'undefined') {
+  // Behaviors are supported.
+  class MyButton extends HTMLElement {
+    static formAssociated = true;
+    static behaviors = [HTMLButtonBehavior];
+
+    #internals;
+    constructor() {
+      super();
+      this.#internals = this.attachInternals();
+    }
+  }
+  customElements.define('my-button', MyButton);
+} else {
+  // Fall back to manual event handling.
+  class MyButton extends HTMLElement {
+    static formAssociated = true;
+
+    #internals;
+    constructor() {
+      super();
+      this.#internals = this.attachInternals();
+      this.addEventListener('click', () => {
+        this.#internals.form?.requestSubmit(this);
+      });
+    }
+  }
+  customElements.define('my-button', MyButton);
+}
+```
+
+### Other considerations
+
+This proposal supports common web component patterns:
+
+- Custom elements using behaviors can follow progressive enhancement patterns: use `<slot>` to render fallback content, provide `<noscript>` alternatives, and design markup to be readable without JavaScript. If script fails to load, the element receives no behavior, which is true for any autonomous custom element with or without this proposal.
+- Because behaviors are pinned to existing algorithms, this framework also enables polyfilling: authors can approximate new behaviors in *userland* before native support ships.
+- While this proposal uses an imperative API, the design supports future declarative custom elements. A declarative form would attach behaviors by a registered string name rather than a class reference. Each built-in behavior would have a canonical token (for example, `HTMLButtonBehavior` registered as `"button"`).
+
+```html
+<my-button behaviors="button">Help</my-button>
+```
+
+### Use case: Design system button
+
+A design system can use a single class with one `HTMLButtonBehavior` and forward the host's `type` attribute to the behavior.
+
+```javascript
+class DesignSystemButton extends HTMLElement {
+  static formAssociated = true;
+  static behaviors = [HTMLButtonBehavior];
+  static observedAttributes = ['type', 'formaction'];
+
+  #internals;
+  #buttonBehavior;
+
+  constructor() {
+    super();
+    this.#internals = this.attachInternals();
+    this.#buttonBehavior = this.#internals.behaviors.get(HTMLButtonBehavior);
+    this.attachShadow({ mode: 'open' });
+  }
+
+  connectedCallback() {
+    this.shadowRoot.innerHTML = '<slot></slot>';
+  }
+
+  attributeChangedCallback(name, _oldValue, newValue) {
+    switch (name) {
+      case 'type': {
+        if (newValue === 'submit' || newValue === 'reset' || newValue === 'button') {
+          this.#buttonBehavior.type = newValue;
+        }
+        break;
+      }
+      case 'formaction': {
+        this.#buttonBehavior.formAction = newValue ?? '';
+        break;
+      }
+    }
+  }
+}
+
+customElements.define('ds-button', DesignSystemButton);
+```
+
+```html
+<form action="/save">
+  <ds-button type="submit">Save</ds-button>
+  <ds-button type="reset">Reset</ds-button>
+  <ds-button type="button" onclick="openHelp()">Help</ds-button>
+</form>
+```
+
+Setting the `type` attribute at runtime flips the active mode through `attributeChangedCallback`, the way an author would expect:
+
+```javascript
+document.querySelector('ds-button').setAttribute('type', 'reset');
+// The behavior's type is now 'reset'. The next activation triggers form reset.
+```

From b802d2b86b0ab2e0a5035f450b4433b4f0f6cc8a Mon Sep 17 00:00:00 2001
From: Ana Sollano Kim <ansollan@microsoft.com>
Date: Tue, 7 Jul 2026 14:28:27 -0700
Subject: [PATCH 2/5] Address feedback I

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---
 .../htmlbuttonbehavior-with-type-attribute.md | 43 ++++++++++---------
 1 file changed, 23 insertions(+), 20 deletions(-)

diff --git a/PlatformProvidedBehaviors/htmlbuttonbehavior-with-type-attribute.md b/PlatformProvidedBehaviors/htmlbuttonbehavior-with-type-attribute.md
index 2420342b2..a2828061b 100644
--- a/PlatformProvidedBehaviors/htmlbuttonbehavior-with-type-attribute.md
+++ b/PlatformProvidedBehaviors/htmlbuttonbehavior-with-type-attribute.md
@@ -55,19 +55,16 @@ Each behavior names the specific platform logic it engages:
 
 ### Behavior categories and composition
 
-Behaviors are organized into a set of categories, expressed as abstract base classes.
+Behaviors are organized into a set of categories. Categories are conceptual groupings the platform uses to decide which behaviors can coexist on one element. They are not classes exposed to authors; authors only ever reference the concrete behaviors (the leaves below).
 
 ```mermaid
 classDiagram
     class ElementBehavior
     class ActivationBehavior {
-        <<abstract>>
-        +activationBehavior(event)
-        +legacyPreActivationBehavior(event)
-        +legacyCanceledActivationBehavior(event)
+        <<category>>
     }
     class EmbeddedContentBehavior {
-        <<abstract>>
+        <<category>>
     }
     class HTMLButtonBehavior
     class HTMLLabelBehavior
@@ -83,7 +80,7 @@ classDiagram
     EmbeddedContentBehavior <|-- HTMLImageBehavior
 ```
 
-`ActivationBehavior` and `EmbeddedContentBehavior` are abstract category bases; the concrete leaves (`HTMLButtonBehavior`, `HTMLLabelBehavior`, `HTMLRadioGroupBehavior`, `HTMLCheckboxBehavior`, `HTMLImageBehavior`) are what an author attaches.
+`ActivationBehavior` and `EmbeddedContentBehavior` are not part of the author-facing API surface. The concrete leaves (`HTMLButtonBehavior`, `HTMLLabelBehavior`, `HTMLRadioGroupBehavior`, `HTMLCheckboxBehavior`, `HTMLImageBehavior`) are the real classes an author attaches.
 
 An element attaches at most one behavior per category. Two behaviors in the same category are mutually exclusive, and attaching both throws a `TypeError`:
 
@@ -129,16 +126,16 @@ customElements.define('image-button', ImageButton);
 </form>
 ```
 
-On activation the host submits the form (from `HTMLButtonBehavior`) while rendering the image and exposing its `alt` text as the accessible name (from `HTMLImageBehavior`). The two behaviors are in different categories, so the platform allows the combination. Because the category is the base class, the platform decides compatibility with a membership test. Adding a new behavior only requires placing it under the right base; it does not require enumerating its compatibility with every existing behavior.
+On activation the host submits the form (from `HTMLButtonBehavior`) while rendering the image and exposing its `alt` text as the accessible name (from `HTMLImageBehavior`). The two behaviors are in different categories, so the platform allows the combination. Each behavior carries its category internally, so the platform checks compatibility with a membership test. Adding a new behavior only requires assigning it a category; it does not require enumerating its compatibility with every existing behavior.
 
-#### `ActivationBehavior`
+#### The activation category
 
-`ActivationBehavior` corresponds to the DOM standard's [activation behavior](https://dom.spec.whatwg.org/#eventtarget-activation-behavior): the algorithm an `EventTarget` runs when a `click` is dispatched to it and not canceled. The DOM standard pairs it with two optional hooks, [legacy-pre-activation behavior](https://dom.spec.whatwg.org/#eventtarget-legacy-pre-activation-behavior) and [legacy-canceled-activation behavior](https://dom.spec.whatwg.org/#eventtarget-legacy-canceled-activation-behavior), which native checkbox and radio use to set checkedness before listeners run and restore it if the event is canceled.
+The activation category corresponds to the DOM standard's [activation behavior](https://dom.spec.whatwg.org/#eventtarget-activation-behavior): the algorithm an `EventTarget` runs when a `click` is dispatched to it and not canceled. The DOM standard pairs it with two optional algorithm hooks, [legacy-pre-activation behavior](https://dom.spec.whatwg.org/#eventtarget-legacy-pre-activation-behavior) and [legacy-canceled-activation behavior](https://dom.spec.whatwg.org/#eventtarget-legacy-canceled-activation-behavior), which native checkbox and radio use to set checkedness before listeners run and restore it if the event is canceled. These are algorithms the platform implements per behavior.
 
-`ActivationBehavior` provides:
+Behaviors in the activation category share:
 
 - Participation in the activation dispatch path (click, keyboard activation, and `element.click()`), honoring `preventDefault()` and `stopPropagation()`.
-- The `legacy-pre-activation behavior` and `legacy-canceled-activation behavior` hooks (no-ops unless overridden).
+- Access to the legacy-pre-activation and legacy-canceled-activation algorithm hooks where a behavior needs them.
 
 Each concrete behavior supplies the rest:
 
@@ -154,16 +151,18 @@ Mapping a few native patterns onto categories helps validate the model:
 |---|---|---|---|
 | `<button>` | `HTMLButtonBehavior` | activation | submit/reset/button via `type`; invoker surface; form participation. |
 | `<label>` | `HTMLLabelBehavior` | activation | `for`-attribute association and focus delegation, activation delegates a click to the labeled control, no implicit role, not focusable. |
-| `<input type=radio>` | `HTMLRadioGroupBehavior` | activation | `name`-based mutual exclusion; needs the `legacy-pre-activation`/`legacy-canceled-activation` hooks for the check-then-restore dance. This is the concrete reason the base exposes those hooks. |
+| `<input type=radio>` | `HTMLRadioGroupBehavior` | activation | `name`-based mutual exclusion; needs the `legacy-pre-activation`/`legacy-canceled-activation` hooks for the check-then-restore dance. This is the reason the category includes those hooks. |
 | `<input type=checkbox>` | `HTMLCheckboxBehavior` | activation | An independent on/off toggle, using the same `legacy-pre-activation`/`legacy-canceled-activation` hooks. |
 
 Of these, `HTMLButtonBehavior`, `HTMLLabelBehavior`, and `HTMLRadioGroupBehavior` are the near-term candidates for future work.
 
 The embedded-content category corresponds to the HTML spec's [embedded content](https://html.spec.whatwg.org/multipage/dom.html#embedded-content-2).
 
+These categories are internal to the platform: authors attach and retrieve behaviors only by their concrete classes, and the platform enforces the one-per-category rule without exposing the categories themselves. If developer-defined behaviors are specified in the future, the categories could be promoted to real, subclassable base classes (for example, `class MyBehavior extends ActivationBehavior`) as an additive change that leaves the `static behaviors` shape untouched.
+
 ### HTMLButtonBehavior
 
-This alternative introduces `HTMLButtonBehavior`, a behavior in the activation category (`class HTMLButtonBehavior extends ActivationBehavior`) that mirrors native `<button>`.
+This alternative introduces `HTMLButtonBehavior`, a behavior in the activation category, that mirrors native `<button>`.
 
 - The behavior has a `type` property (`'submit'` (default), `'reset'`, or `'button'`) that selects the active button mode. The `type` is mutable for the life of the behavior.
 - User activation (click, Enter, Space, implicit submission) reaches the behavior through the same DOM event-dispatch path as native elements.
@@ -211,7 +210,7 @@ To expose these properties to external code, authors define getters and setters
 | Event | What happens |
 |-------|--------------|
 | Element creation (`new`, parser upgrade, or `customElements.upgrade()`) | The platform instantiates each declared behavior with its defined defaults. The behavior's `type` selects the initial active button mode (`'submit'` by default). Role, focusability, and pseudo-class participation are active from this point. |
-| `attachInternals()` | `internals.behaviors` is populated with the already-existing behavior instances. Authors now have read/write access through `internals.behaviors.get(ElementBehavior)`. |
+| `attachInternals()` | `internals.behaviors` is populated with the already-existing behavior instances. Authors have read/write access through `internals.behaviors.get(HTMLButtonBehavior)`. |
 | Host connected | Form association runs if `formAssociated = true`. The behavior's `form` is resolved. |
 | `behavior.type` set to a new value | Form ownership, role, focusability, and pseudo-class state are recomputed. See [Mutating the `type` property](#mutating-the-type-property). |
 | Host disconnected | Form association detaches. The behavior remains attached for when the host re-connects. |
@@ -250,10 +249,14 @@ Authors declare behaviors via a static class property; the platform creates and
 
 #### Classes vs a string-based API
 
-Behaviors are class references, not string tokens. An earlier proposal, [`elementInternals.type`](https://github.com/whatwg/html/issues/11061), collected consistent feedback that a string opt-in is the wrong shape for this problem. That feedback motivates the class-based design used here.
+Behaviors are class references, not string tokens. An earlier proposal, [`elementInternals.type`](https://github.com/whatwg/html/issues/11061), took the string approach.
+
+The one substantive reason to prefer classes is extensibility. A string enum is a closed set the platform owns, so it closes the door on developer-defined behaviors. A class reference keeps that door open: the `static behaviors` array that takes `HTMLButtonBehavior` could just take an author's own class. [A comment on the thread](https://github.com/whatwg/html/issues/11061#issuecomment-3146290495) raised this as the gap in the string design.
+
+Beyond that, we are open to a string-based API instead. The [TAG endorses string constants](https://www.w3.org/TR/design-principles/#string-constants) for selecting from a fixed set, and the objections raised against strings in the thread are either shared with the class approach or resolvable:
 
-- A misspelled token has no good failure mode. [As noted in the discussion](https://github.com/whatwg/html/issues/11061#issuecomment-3146290495), `static activationBehavior = 'buton'` "likely [...] can't throw," so the typo silently does nothing. A class reference is resolved by the JavaScript engine, so a misspelled `HTMLButtnBehavior` is a `ReferenceError` at parse time instead of a no-op.
-- String tokens are not discoverable. The [same comment](https://github.com/whatwg/html/issues/11061#issuecomment-3146290495) adds that string tokens are "not super discoverable [...] there is no additional API surface to discover." A behavior class carries its own surface (properties, methods, and an `instanceof` relationship) that authors and tooling can inspect. See [Behaviors are not opaque tokens](#behaviors-are-not-opaque-tokens).
+- Typos are not unique to strings. A misspelled identifier throws a `ReferenceError`, but a wrong-but-valid class (`static behaviors = [HTMLButtonElement]`) fails just as silently as a bad string; both can only be rejected when `customElements.define()` validates the array. A string token can be validated the same way, throwing on an unknown value.
+- Discoverability is resolvable. A string is opaque on its own, but an author can inspect a behavior's surface at runtime through the instance from `internals.behaviors`, and the set of tokens can be documented and feature-detected.
 
 #### One `behaviors` array vs per-category slots
 
@@ -279,13 +282,13 @@ static behaviors = {
 };
 ```
 
-`HTMLButtonBehavior extends ActivationBehavior`, so its category is intrinsic. Naming the slot (`activationBehavior:`) restates that. It also forces the author to know the right key for every behavior, and a wrong key (`replacedContent: HTMLButtonBehavior`) becomes a new failure mode. A single flat array avoids all of it:
+`HTMLButtonBehavior` belongs to the activation category, so its category is intrinsic. Naming the slot (`activationBehavior:`) restates that. It also forces the author to know the right key for every behavior, and a wrong key (`replacedContent: HTMLButtonBehavior`) becomes a new failure mode. A single flat array avoids all of it:
 
 ```javascript
 static behaviors = [HTMLButtonBehavior, HTMLImageBehavior];
 ```
 
-The platform reads each behavior's category from its base class, so it enforces one behavior per category on its own (see [Behavior categories and composition](#behavior-categories-and-composition)). The declaration stays short as categories are added, and each behavior is named once.
+The platform knows each behavior's category, so it enforces one behavior per category on its own (see [Behavior categories and composition](#behavior-categories-and-composition)). The declaration stays short as categories are added, and each behavior is named once.
 
 ### Feature detection
 

From 81f3b838be4574f7c056c712c87254eae1d8ce34 Mon Sep 17 00:00:00 2001
From: Ana Sollano Kim <ansollan@microsoft.com>
Date: Wed, 8 Jul 2026 15:18:30 -0700
Subject: [PATCH 3/5] Addressing feedback II

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---
 .../htmlbuttonbehavior-with-type-attribute.md | 29 +++++++++----------
 1 file changed, 13 insertions(+), 16 deletions(-)

diff --git a/PlatformProvidedBehaviors/htmlbuttonbehavior-with-type-attribute.md b/PlatformProvidedBehaviors/htmlbuttonbehavior-with-type-attribute.md
index a2828061b..30b147913 100644
--- a/PlatformProvidedBehaviors/htmlbuttonbehavior-with-type-attribute.md
+++ b/PlatformProvidedBehaviors/htmlbuttonbehavior-with-type-attribute.md
@@ -9,7 +9,7 @@ Four things motivate this alternative:
 
 1. Modeling the button types as three separate behaviors duplicates most of the surface to express activation differences.
 2. Web authors who want a single custom element class that can switch between submit, reset, and generic-button at runtime also want one element with one mutable property. A single `HTMLButtonBehavior` with a mutable `type` avoids having to define what happens when two button-shaped behaviors are attached at once and one is toggled off.
-3. It matches native `<button>` and frameworks also use this shape.
+3. It matches native `<button>`, and many frameworks also use this shape.
 4. The platform owns instantiation; authors look up state through `ElementInternals`.
 
 ## Proposed approach
@@ -18,7 +18,7 @@ A platform-provided behavior is a set of methods, values, and platform-protocol
 
 The platform reads `static behaviors` at `customElements.define()` time and stores it on the custom element definition, the same way it reads `static formAssociated`. When an element is created (`new`, parser upgrade, or `customElements.upgrade()`), the platform instantiates one of each declared behavior per host and associates them with the element. This mirrors how a form-associated custom element participates in form submission and form-related lifecycle callbacks.
 
-`attachInternals()` is the author's access route to those already-existing instances, exposed through a new `behaviors` collection on `ElementInternals`. The set of behaviors attached to a host is fixed at the class declaration; the behavior instances themselves remain mutable post-attachment.
+`attachInternals()` is the author's access route to those already-existing instances, exposed through a new `behaviors` collection on `ElementInternals`. The set of behaviors attached to a host is fixed at the class declaration; the behavior instances' own properties remain mutable post-attachment.
 
 ```javascript
 class CustomButton extends HTMLElement {
@@ -165,14 +165,15 @@ These categories are internal to the platform: authors attach and retrieve behav
 This alternative introduces `HTMLButtonBehavior`, a behavior in the activation category, that mirrors native `<button>`.
 
 - The behavior has a `type` property (`'submit'` (default), `'reset'`, or `'button'`) that selects the active button mode. The `type` is mutable for the life of the behavior.
-- User activation (click, Enter, Space, implicit submission) reaches the behavior through the same DOM event-dispatch path as native elements.
+- User activation (click, Enter, Space, implicit submission) reaches the behavior through the same DOM event-dispatch path as native elements. Author-added event listeners for those same modalities coexist with the behavior: they fire during normal dispatch, and calling `preventDefault()` cancels the behavior's activation, matching native `<button>`.
 - The behavior provides a default implicit `role="button"`. Authors can override the role through `internals.role`.
+- The host is exposed to the accessibility tree with its `button` role and an accessible name computed from its contents, and disabled and default state are surfaced to assistive technologies, so AT users get the same information as for a native `<button>`.
 - The custom element with HTMLButtonBehavior participates in sequential focus navigation, with `tabindex` and disabled state following established rules.
 - The same logic that toggles `:default`, `:disabled`/`:enabled`, `:focus`, and `:focus-visible` on native elements applies to the behavior's host. The `:default` pseudo-class only matches when `type === 'submit'` and the host is the form's default submit button.
 - Mirrored `HTMLButtonElement` properties are available on the behavior instance. They are configurable per-element and mutable for the life of the behavior.
 - Form ownership applies whenever `type` is `'submit'` or `'reset'`. Activation behavior depends on `type`: `'submit'` triggers form submission and implicit submission; `'reset'` triggers form reset; `'button'` does generic activation.
 
-`HTMLButtonBehavior` builds on top of [form-associated custom elements (FACEs)](https://html.spec.whatwg.org/multipage/custom-elements.html#form-associated-custom-elements). The custom element still has to opt in to form association with `static formAssociated = true` for submission to actually fire when `type` is `'submit'` or `'reset'`. Without it, `behavior.form` is always `null` and activation is a no-op even when the element is inside a form. This is a divergence from native `<button>`, which submits its form without any explicit opt-in.
+`HTMLButtonBehavior` builds on top of [form-associated custom elements (FACEs)](https://html.spec.whatwg.org/multipage/custom-elements.html#form-associated-custom-elements). The custom element still has to opt in to form association with `static formAssociated = true` for submission to actually fire when `type` is `'submit'` or `'reset'`. Without it, `behavior.form` is always `null` and activation is a no-op even when the element is inside a form. This is a divergence from native `<button>`, which submits its form without any explicit opt-in. The platform could later imply form association, removing the extra opt-in.
 
 | Scenario | Behavior |
 |----------|----------|
@@ -187,7 +188,7 @@ A recurring concern about consolidating form-control semantics into an opt-in is
 
 - Each element behavior maps to a single native pattern (e.g., `HTMLButtonBehavior` provides exactly the semantics of `<button>`). Future element behaviors will need to follow the same naming convention.
 - Each behavior is specified in terms of existing HTML algorithms. The behavior is the union of those algorithms, applied to a custom element.
-- Web authors can override individual defaults. This already works today for role: `internals.role` overrides a behavior's default role without replacing the behavior. The same layering pattern can extend to other defaults (focusability, keyboard activation, and similar) if and when future proposals add the corresponding primitives on `ElementInternals`.
+- Web authors can override individual defaults. This already works today for role: `internals.role` overrides a behavior's default role without replacing the behavior. The same layering pattern can extend to other defaults (focusability, keyboard activation, and similar) if and when future proposals add the corresponding primitives on `ElementInternals`. The layering example in [Alternative 7](https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/PlatformProvidedBehaviors/explainer.md#alternative-7-low-level-primitives-on-elementinternals) walks through what that would look like.
 
 ### Accessing behavior state
 
@@ -258,9 +259,9 @@ Beyond that, we are open to a string-based API instead. The [TAG endorses string
 - Typos are not unique to strings. A misspelled identifier throws a `ReferenceError`, but a wrong-but-valid class (`static behaviors = [HTMLButtonElement]`) fails just as silently as a bad string; both can only be rejected when `customElements.define()` validates the array. A string token can be validated the same way, throwing on an unknown value.
 - Discoverability is resolvable. A string is opaque on its own, but an author can inspect a behavior's surface at runtime through the instance from `internals.behaviors`, and the set of tokens can be documented and feature-detected.
 
-#### One `behaviors` array vs per-category slots
+#### One `behaviors` array vs per-category fields
 
-Even with classes instead of strings, the declaration could be split into one named opt-in per category. [Issue #1353](https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/1353) proposes a `static activationBehavior` next to a `static replacedContent`, each set to a cluster keyword, so conflicts resolve at the WebIDL level: one slot per category.
+Even with classes instead of strings, the declaration could be split into one named opt-in per category. [Issue #1353](https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/1353) proposes a `static activationBehavior` next to a `static replacedContent`, each set to a cluster keyword, so conflicts resolve at the WebIDL level: one field per category.
 
 ```javascript
 // Per-category string clusters (issue #1353)
@@ -268,10 +269,10 @@ static activationBehavior = 'button';
 static replacedContent = 'image';
 ```
 
-The keywords carry the [same problems](#classes-vs-a-string-based-api). Substituting classes keeps the per-slot shape while repeating what the class already encodes:
+The keywords carry the [same problems](#classes-vs-a-string-based-api). Substituting classes keeps the per-field shape while repeating what the class already encodes:
 
 ```javascript
-// Per-category slots, with classes
+// Per-category fields, with classes
 static activationBehavior = HTMLButtonBehavior;
 static replacedContent = HTMLImageBehavior;
 
@@ -282,7 +283,7 @@ static behaviors = {
 };
 ```
 
-`HTMLButtonBehavior` belongs to the activation category, so its category is intrinsic. Naming the slot (`activationBehavior:`) restates that. It also forces the author to know the right key for every behavior, and a wrong key (`replacedContent: HTMLButtonBehavior`) becomes a new failure mode. A single flat array avoids all of it:
+`HTMLButtonBehavior` belongs to the activation category, so its category is intrinsic. Naming the field (`activationBehavior:`) restates that. It also forces the author to know the right key for every behavior, and a wrong key (`replacedContent: HTMLButtonBehavior`) becomes a new failure mode. A single flat array avoids all of it:
 
 ```javascript
 static behaviors = [HTMLButtonBehavior, HTMLImageBehavior];
@@ -331,12 +332,8 @@ if (typeof HTMLButtonBehavior !== 'undefined') {
 This proposal supports common web component patterns:
 
 - Custom elements using behaviors can follow progressive enhancement patterns: use `<slot>` to render fallback content, provide `<noscript>` alternatives, and design markup to be readable without JavaScript. If script fails to load, the element receives no behavior, which is true for any autonomous custom element with or without this proposal.
-- Because behaviors are pinned to existing algorithms, this framework also enables polyfilling: authors can approximate new behaviors in *userland* before native support ships.
-- While this proposal uses an imperative API, the design supports future declarative custom elements. A declarative form would attach behaviors by a registered string name rather than a class reference. Each built-in behavior would have a canonical token (for example, `HTMLButtonBehavior` registered as `"button"`).
-
-```html
-<my-button behaviors="button">Help</my-button>
-```
+- Because behaviors are pinned to existing algorithms, this framework also enables polyfilling: authors can approximate new behaviors in *userland* before native support ships, though some capabilities (CSS pseudo-classes in particular) can only be partially approximated, often at a performance cost.
+- While this proposal uses an imperative API, the design supports a future declarative form that would attach behaviors by a registered string name rather than a class reference. That declarative approach will be proposed separately once the imperative shape is agreed upon.
 
 ### Use case: Design system button
 

From ed3f9dabc26f4deb65adde882b4eaf17d166160b Mon Sep 17 00:00:00 2001
From: Ana Sollano Kim <ansollan@microsoft.com>
Date: Mon, 13 Jul 2026 15:30:38 -0700
Subject: [PATCH 4/5] Addressing feedback III

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---
 .../htmlbuttonbehavior-with-type-attribute.md               | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/PlatformProvidedBehaviors/htmlbuttonbehavior-with-type-attribute.md b/PlatformProvidedBehaviors/htmlbuttonbehavior-with-type-attribute.md
index 30b147913..ea4128d9e 100644
--- a/PlatformProvidedBehaviors/htmlbuttonbehavior-with-type-attribute.md
+++ b/PlatformProvidedBehaviors/htmlbuttonbehavior-with-type-attribute.md
@@ -86,8 +86,8 @@ An element attaches at most one behavior per category. Two behaviors in the same
 
 ```javascript
 static behaviors = [HTMLButtonBehavior, HTMLLabelBehavior]; // throws!
-// TypeError: an element can have at most one ActivationBehavior;
-// HTMLButtonBehavior and HTMLLabelBehavior cannot be combined.
+// TypeError: HTMLButtonBehavior and HTMLLabelBehavior cannot be combined;
+// an element can have only one activation behavior.
 ```
 
 Behaviors in different categories compose. Combining an `HTMLButtonBehavior` (activation) with an `HTMLImageBehavior` (embedded content) produces a submit button that renders as an image, similar to [`<input type=image>`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/image):
@@ -291,6 +291,8 @@ static behaviors = [HTMLButtonBehavior, HTMLImageBehavior];
 
 The platform knows each behavior's category, so it enforces one behavior per category on its own (see [Behavior categories and composition](#behavior-categories-and-composition)). The declaration stays short as categories are added, and each behavior is named once.
 
+However, a per-field shape (like the one expressed in [issue #1353](https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/1353)) has the advantage that same-category collisions become impossible to express rather than something the platform rejects at definition time. The cost is that per-category fields put the category shape back into the author-facing declaration, which this proposal keeps internal.
+
 ### Feature detection
 
 Web authors can detect whether behaviors are supported by checking for the existence of behavior classes on the global scope:

From 47b77d5853f2a783c2857c663098efd52051b2e4 Mon Sep 17 00:00:00 2001
From: Ana Sollano Kim <ansollan@microsoft.com>
Date: Tue, 14 Jul 2026 16:59:57 -0700
Subject: [PATCH 5/5] Addressing feedback IV

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
---
 .../htmlbuttonbehavior-with-type-attribute.md | 37 +++++++++----------
 1 file changed, 17 insertions(+), 20 deletions(-)

diff --git a/PlatformProvidedBehaviors/htmlbuttonbehavior-with-type-attribute.md b/PlatformProvidedBehaviors/htmlbuttonbehavior-with-type-attribute.md
index ea4128d9e..e8f8b9178 100644
--- a/PlatformProvidedBehaviors/htmlbuttonbehavior-with-type-attribute.md
+++ b/PlatformProvidedBehaviors/htmlbuttonbehavior-with-type-attribute.md
@@ -259,39 +259,36 @@ Beyond that, we are open to a string-based API instead. The [TAG endorses string
 - Typos are not unique to strings. A misspelled identifier throws a `ReferenceError`, but a wrong-but-valid class (`static behaviors = [HTMLButtonElement]`) fails just as silently as a bad string; both can only be rejected when `customElements.define()` validates the array. A string token can be validated the same way, throwing on an unknown value.
 - Discoverability is resolvable. A string is opaque on its own, but an author can inspect a behavior's surface at runtime through the instance from `internals.behaviors`, and the set of tokens can be documented and feature-detected.
 
-#### One `behaviors` array vs per-category fields
+#### Open question: one `behaviors` array or per-category properties
 
-Even with classes instead of strings, the declaration could be split into one named opt-in per category. [Issue #1353](https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/1353) proposes a `static activationBehavior` next to a `static replacedContent`, each set to a cluster keyword, so conflicts resolve at the WebIDL level: one field per category.
+There are two natural shapes for declaring which behaviors the platform attaches. Both enforce the one-behavior-per-category rule; they differ in where that rule lives.
+
+The first is a single array of behavior classes:
 
 ```javascript
-// Per-category string clusters (issue #1353)
-static activationBehavior = 'button';
-static replacedContent = 'image';
+static behaviors = [HTMLButtonBehavior, HTMLImageBehavior];
 ```
 
-The keywords carry the [same problems](#classes-vs-a-string-based-api). Substituting classes keeps the per-field shape while repeating what the class already encodes:
+The second is one static property per category, each holding a single behavior class:
 
 ```javascript
-// Per-category fields, with classes
 static activationBehavior = HTMLButtonBehavior;
-static replacedContent = HTMLImageBehavior;
-
-// Or one object keyed by category
-static behaviors = {
-  activationBehavior: HTMLButtonBehavior,
-  replacedContent: HTMLImageBehavior,
-};
+static embeddedContentBehavior = HTMLImageBehavior;
 ```
 
-`HTMLButtonBehavior` belongs to the activation category, so its category is intrinsic. Naming the field (`activationBehavior:`) restates that. It also forces the author to know the right key for every behavior, and a wrong key (`replacedContent: HTMLButtonBehavior`) becomes a new failure mode. A single flat array avoids all of it:
+[Issue #1353](https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/1353) first raised the per-category shape using string keywords (`static activationBehavior = 'button'`); the [reasons to prefer classes over strings](#classes-vs-a-string-based-api) apply equally here, so the comparison below is between an array of classes and one class-valued property per category. A single object keyed by category (`static behaviors = { activationBehavior: HTMLButtonBehavior }`) is a third variant that shares the drawbacks of both.
 
-```javascript
-static behaviors = [HTMLButtonBehavior, HTMLImageBehavior];
-```
+The two shapes have the following trade-offs:
 
-The platform knows each behavior's category, so it enforces one behavior per category on its own (see [Behavior categories and composition](#behavior-categories-and-composition)). The declaration stays short as categories are added, and each behavior is named once.
+| Consideration | `behaviors` array | Per-category properties |
+|---|---|---|
+| Same-category collision | The platform rejects it at `customElements.define()` time (a runtime check). | Impossible to express, since there is only one property per category. |
+| Category visibility | An author writes the behavior class and never names its category. | An author has to know that a button is an activation behavior and which property it belongs in. |
+| Precedent | New pattern. | Matches how custom elements already opt into platform features (`static formAssociated`, `static observedAttributes`). |
+| Growth | Absorbs new categories without changing shape. | Each new category adds a static property to the API surface. |
+| (Future) Developer-defined behaviors | Would accept an author's own class directly. | Would need a separate category. |
 
-However, a per-field shape (like the one expressed in [issue #1353](https://github.com/MicrosoftEdge/MSEdgeExplainers/issues/1353)) has the advantage that same-category collisions become impossible to express rather than something the platform rejects at definition time. The cost is that per-category fields put the category shape back into the author-facing declaration, which this proposal keeps internal.
+This document uses the array form in its examples, but the choice is unresolved.
 
 ### Feature detection