[Platform-provided behaviors for CE] HTMLButtonBehavior with type attribute alternative

[anaskim]

Not for merging, just getting comments/feedback in-line.

[dandclark]

At a first pass through, I like this. Just left some general early thoughts on the design.

[gregwhitworth]

Some general questions and primarily "nits". Thank you so much for your great work on this.

[gregwhitworth]

@slightlyoff raised at one point in this conversation why we're having abstractions. I think it's worth outlining why we're doing this bucketing rather than giving them more granular access. I personally like this design as I think 99% of authors are going to just want all of the goodness out of the box and also not have to keep adding capabilities as we introduce them into the platform (this is coming from years of having to support something similar) but it's worth noting (maybe in appendix or similar) why we're not currently exploring this path. I'm interested in @dandclark and your thoughts as this may also open a can of worms.

[anaskim]

Agreed this deserves to be written down. The granular / à-la-carte path (expose focusability, activation, form participation, etc. as independent primitives) is the low-level-primitives direction in Alternative 7 of the main explainer. When I move this alternative into the main explainer, I will leave the comments pointing to the granular approach.

[gregwhitworth]

I really think this table is a great example of the power this provides

[anaskim]

Thanks for the thorough feedback!

[anaskim]

Agreed this deserves to be written down. The granular / à-la-carte path (expose focusability, activation, form participation, etc. as independent primitives) is the low-level-primitives direction in Alternative 7 of the main explainer. When I move this alternative into the main explainer, I will leave the comments pointing to the granular approach.

[gregwhitworth]

Thanks for the edits, I'm a go :)

[mohamedmansour]

The premise of platform-provided behaviors is that authors delete JS and the platform runs the equivalent logic natively. If property and event surface still has to be forwarded in JS, that premise only half-holds, the code moves rather than disappears.

If the platform reflected a behavior's properties and events onto the host, bundle size/construction cost/access cost go to zero. No bytes shipped, no per-instance setup, native property access. That's the difference between "custom elements can approximate built-ins" and "custom elements can match built-ins."

I'd rather write something like this:

class MoSwitch extends HTMLElement {
  static formAssociated = true;
  static behaviors = [HTMLCheckboxBehavior];
}

And have e el.checked, el.indeterminate, and change/input just work, than write the same forwarding layer in every control, in every design system.

[anaskim]

The premise of platform-provided behaviors is that authors delete JS and the platform runs the equivalent logic natively. If property and event surface still has to be forwarded in JS, that premise only half-holds, the code moves rather than disappears.

If the platform reflected a behavior's properties and events onto the host, bundle size/construction cost/access cost go to zero. No bytes shipped, no per-instance setup, native property access. That's the difference between "custom elements can approximate built-ins" and "custom elements can match built-ins."

I'd rather write something like this:

class MoSwitch extends HTMLElement {
  static formAssociated = true;
  static behaviors = [HTMLCheckboxBehavior];
}

And have e el.checked, el.indeterminate, and change/input just work, than write the same forwarding layer in every control, in every design system.

@mohamedmansour This is fair. I think Adobe also asked about this. I'd say if we can't offer this by default, there should be a way of opting-in and letting the browser do the reflection. Thanks for the comment, I'll take a look and discuss more.

[mohamedmansour]

Thanks @anaskim, an opt-in would work for me. Two things that might help the discussion:

My preference is reflection on by default, because "behaves like a checkbox" is what an author asks for, and having to say so twice is a redundant. But an opt-in that's a single declaration is fine, the thing I want to avoid is per-property forwarding. Something like:

static behaviors = [HTMLCheckboxBehavior];
static reflectBehaviors = true;   // or per-behavior: [{ behavior: HTMLCheckboxBehavior, reflect: true }]

The reason to keep it opt-in is presumably name collisions, an author who already defines checked on their class, or wants different semantics. That argues for reflection being additive and losing to an own class member rather than throwing: if the class defines the property, the class wins, otherwise the platform installs it. That way opting in is safe and doesn't require auditing your class first.

Same question applies to events, I'd want input/change dispatching from the host without a re-dispatch layer, since a re-dispatched event isn't identical (composed/trusted/timing) and costs a listener per instance.