Skip to content

Platform provided behaviors feedback 9#1293

Open
anaskim wants to merge 4 commits intoMicrosoftEdge:mainfrom
anaskim:main
Open

Platform provided behaviors feedback 9#1293
anaskim wants to merge 4 commits intoMicrosoftEdge:mainfrom
anaskim:main

Conversation

@anaskim
Copy link
Copy Markdown
Contributor

@anaskim anaskim commented Apr 1, 2026

Updates

  • Resolve open question on automatically exposing attributes and properties on the element rather than on the behavior.
  • Resolve to propose the current API shape where web developers would hold direct references to behaviors.

@anaskim anaskim marked this pull request as ready for review April 2, 2026 17:57
@anaskim anaskim requested review from dandclark and leotlee April 2, 2026 17:59
this._tooltipBehavior.content = 'Helpful tooltip text';
```

#### Alternative 1: Class references
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we keep this but move it to the "Alternatives considered" section towards the end of the document?

**Cons:**
- Requires developers to manage behavior instances themselves.
- More setup code compared to passing class references directly.
With the current approach, developers hold direct references to their behavior instances: no array lookup, `instanceof` checks, or `behaviors` interface is needed to access behavior state. It also aligns with the [W3C design principle that classes should have constructors](https://www.w3.org/TR/design-principles/#constructors) that allow authors to create and configure instances, and it extends naturally to future developer-defined behaviors that follow the same `new` + attach pattern.
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
With the current approach, developers hold direct references to their behavior instances: no array lookup, `instanceof` checks, or `behaviors` interface is needed to access behavior state. It also aligns with the [W3C design principle that classes should have constructors](https://www.w3.org/TR/design-principles/#constructors) that allow authors to create and configure instances, and it extends naturally to future developer-defined behaviors that follow the same `new` + attach pattern.
Developers hold direct references to their behavior instances. This aligns with the [W3C design principle that classes should have constructors](https://www.w3.org/TR/design-principles/#constructors) that allow authors to create and configure instances, and it extends naturally to future developer-defined behaviors that follow the same `new` + attach pattern.

Suggested rewording now that the "class references" alternative is no longer being directly compared to this approach.

}
```

*Note: Automatic exposure would require adding behavior properties (e.g., `formAction`, `name`, `value`) to `HTMLElement`. This would bloat every `HTMLElement` instance's prototype with properties that only make sense for elements with specific behaviors. An opt-in alternative was considered but adds API complexity without a clear benefit.*
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we need to include this note here if we instead keep the Class References alternative section and move it to Considered Alternatives near the end of the doc per my other suggestion.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants