Custom attributes for all elements

• Upcoming
• Tentative
• Breakout Sessions

2023's breakouts had a discussion on alternatives to customized built-ins.

A sketch of a proposal came out around this time: customised attributes. https://github.com/WICG/webcomponents/issues/1029

I'd like to set some time to discuss this idea, the merits, complexities, and discuss whether or not this solves problems for developers without too much complexity for the platform.

Agenda

Chairs:
Keith Cirkel, Lea Verou

Description:
2023's breakouts had a discussion on alternatives to customized built-ins.

A sketch of a proposal came out around this time: customised attributes. https://github.com/WICG/webcomponents/issues/1029

I'd like to set some time to discuss this idea, the merits, complexities, and discuss whether or not this solves problems for developers without too much complexity for the platform.

Goal(s):
Decide if a model for Custom Attributes is viable in the platform, and what a design might look like.

Agenda:

1. Can we reasonably enforce that HTML will only standardise attribute names without dashes, and developers can use dashes (modulo data-* and aria-*); see https://github.com/whatwg/html/issues/2271
2. Can we agree that pursuing a series of lifecycle callbacks for when an attribute node is connected, disconnected, and changed would be a useful feature for developers, and something that the major browser vendors would be happy pursuing.
3. Do we agree that class CustomAttr extends Attr {} is a good design choice? This means giving Attr() a constructor, and would be getAttributeNode() etc could now return subclasses of Attr. It would also mean setAttribute/removeAttribute/toggleAttribute would run these lifecycles, including: looking up the attribute name in some form of registry, & calling into script. Is this okay?
4. Can Attrs leverage CEReactions or would we need some kind of new CAReactions?
5. Reflection is useful for attributes, could we design a way to bake reflection into custom attribute nodes? E.g. static reflectedAs = "long" which would change the behaviour of Attr.prototype.value for such custom attributes.
6. Default values for attributes is useful, can we design something like static defaultValue = ...?
7. We would likely need some kind of attribute registry (much like window.customElements). Does window.customAttributes make sense? Perhaps we wish to define attributes only for specific elements, such as <button>, how would that work?
8. Custom Element authors may well wish to scope attributes like they do scoped elements, should we do something similar to shadowRoot.customElementRegistry? How does this interplay with per-element attributes (see above)?
9. What powers can we give attributes to alter their ownerElements? We likely don't want to give access to all of ElementInternals but for e.g. attributes might want to provide a minimum accessible role or expose custom states.
10. Often times attributes are paired or at-least coordinate, popovertarget/popovertargetaction, command/commandfor, type/value. How can custom attribute authors ergonomically co-operate?

Materials:

• Session proposal on GitHub

Joining Instructions

Instructions are restricted to W3C users . You need to log in to see them.

Export options

Personal Links

Please log in to export this event with all the information you have access to.

Public Links

The following links do not contain any sensitive information and can be shared publicly.

• Download as ics