Custom attributes for all elements

[keithamus]

Session 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. WICG/webcomponents#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.

Session goal

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

Additional session chairs (Optional)

@keithamus, @LeaVerou

Who can attend

Anyone may attend (Default)

Instructions for meeting planners (Optional)

No response

IRC channel (Optional)

#custom-attrs

Agenda for the meeting.

1. Can we reasonably enforce that HTML will only standardise attribute names without dashes, and developers can use dashes (modulo data-* and aria-*); see Make custom attribute rules consistent with custom element name rules whatwg/html#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?

Scheduling conflicts to avoid (For meeting planners only)

No response

Links to calendar

• Wednesday, 16:15 - 17:15

Meeting materials

• Minutes

[tpac-breakout-bot]

Thank you for proposing a session!

You may update the session description as needed and at any time before the meeting, but please keep in mind that tooling relies on issue formatting: follow the instructions and leave all headings and other formatting intact in particular.

Bots and W3C TPAC breakouts organizers may update the description at any time, to fix formatting issues or add links and other relevant information. Please do not revert these changes. Feel free to use comments to raise questions.

Do not expect formal approval; W3C TPAC breakouts organizers endeavor to schedule all proposed sessions that are in scope for a breakout. Actual scheduling should take place shortly before the meeting.