w3c/tpac2023-breakouts

Alternative to customized builtins (custom elements with is=)

rniwa opened this issue · 9 comments

rniwa commented

Session description

This is a session to discuss an alternative to customized builtins based on the outcome of WebKit/standards-positions#97

Session goal

Come up with a concrete alternative proposal with multi-vendor support to customized builtins

Additional session chairs (Optional)

No response

IRC channel (Optional)

#webcomponents

Who can attend

Anyone may attend (Default)

Session duration

60 minutes (Default)

Other sessions where we should avoid scheduling conflicts (Optional)

#13, #14, #15

Estimated number of in-person attendees

Don't know (Default)

Instructions for meeting planners (Optional)

No response

Agenda, minutes, slides, etc. (Optional)

rniwa commented

Here are some (non-exhaustive list of) concrete proposals:

tidoust commented

People not involved in Web Components discussions may wonder what "customized builtins" refers to. @rniwa, would you mind adjusting the title to better clarify the link to custom elements, e.g., "Alternative to customized builtins HTML elements"?

rniwa commented

Done.

  • 👍1
annevk commented

F2F session is starting now. Minutes will be created here: https://docs.google.com/document/d/10hRHzZWwBuz0aJqBZ63alfzYBxKdhN8WINHizioNfok/edit.

LeaVerou commented

My Notes from the meeting:

  • It sounds like there are 2 orthogonal issues here - one is if it is one new attribute (e.g. has="") with multiple values vs arbitrary hyphenated names. The other is whether custom attributes are sufficient or whether we also need the ability to add methods, properties, decorators etc.

Scoping

Whichever solution we go with should support a mechanism for scoping to specific local names, classes (e.g. HTMLInputElement) or both.

  • Local names are ambiguous (scoped registries, namespaces, e.g. does scoping to "a" also add the behavior to SVG's <a> elements?
  • Classes allow adding behaviors/attributes to anonymous elements, i.e. elements before they are registered (though this can be mitigated with CustomElementRegistry#whenDefined().
  • Classes are not equal across realms, though you'd need to register things separately in another realm anyway, so maybe that's not much of a problem
  • Classes can be too broad, e.g. HTMLHeadingElement spans <h1> to <h6>, HTMLMediaElement includes both <video> and <audio> etc. Unclear if there are use cases that require more specificity; also we do need to draw the line somewhere, e.g. there are use cases that require even more granularity than local names (e.g. what if I want to add a behavior to <input type="color">).
  • If we have enough use cases for both, we may want to allow both, e.g. an array of classes OR strings.
  • If custom attributes add properties to reflect the attributes (which I'd strongly recommend), it needs to be scoped by class reference so that the properties can become part of the prototype

Benefits of custom attributes

  • They "feel" more first class than a list of identifiers within a shared attribute
  • They can take values as well, whereas enhancements cannot be parameterized
  • Paving the cowpaths: I originally proposed custom attributes in 2017), as a way to "legalize" what developers were already doing, i.e. defining hyphenated attributes with a common prefix (e.g. VueJS, older Angular, AlpineJS, htmx etc).
  • So much potential beyond just augmenting built-ins or other custom elements: e.g. if they automate attribute-property reflection (which is currently really hard), they could even be useful in defining a WCs own attributes.

Drawbacks of custom attributes

  • Custom attributes do not provide no way to add methods, or properties (without attributes).

The more I think about this, the more I'm convinced we need both, as a layered solution with one building on top of the other: custom attributes for simple enhancements that only require attributes, enhancements that build on top of custom attributes, but can also include other types of enhancements, inline with simple things being easy, and complex things being possible.

I will try to come up with a proposal that puts all of these pieces together.

  • 👍3
bahrus commented

One point not raised yet (at the risk of jumping the shark to making complex things without first making easy things) -- do we want to filter out based on things like the type of the input element (text vs datepicker)? Maybe that could be done within the code, but just wanted to raise the question.

LeaVerou commented

One point not raised yet (at the risk of jumping the shark to making complex things without first making easy things) -- do we want to filter out based on things like the type of the input element (text vs datepicker)? Maybe that could be done within the code, but just wanted to raise the question.

It has been raised:

  • Classes can be too broad, e.g. HTMLHeadingElement spans <h1> to <h6>, HTMLMediaElement includes both <video> and <audio> etc. Unclear if there are use cases that require more specificity; also we do need to draw the line somewhere, e.g. there are use cases that require even more granularity than local names (e.g. what if I want to add a behavior to <input type="color">).
  • 👍1
LeaVerou commented

Ok, I posted some initial thoughts here: WICG/webcomponents#1029
Super handwavy at this point, but I wanted to get something out earlier rather than later.

  • 👍1