We have Custom Elements, but do we also need Custom Attributes?

This was discussed at TPAC. Is it something you'd like on the platform?

http://github.com/WICG/webcomponents/issues/1029

@FirefoxDevTools @jaffathecake Jake it is so nice to have you on my screen again 😭 and the way you present is also so pleasant
@Anneke @FirefoxDevTools Aww thank you! I'm having lots of fun making these

@FirefoxDevTools similar to this idea, but slightly different, is the idea of element controllers, where an attribute is used to attach functionality to an element, for example https://github.com/DarkWiiPlayer/controller-registry

I would love this, as I often end up making custom elements that wrap some element in order to add functionality to it

GitHub - DarkWiiPlayer/controller-registry

Contribute to DarkWiiPlayer/controller-registry development by creating an account on GitHub.

GitHub

@FirefoxDevTools Yes! I would very much welcome this, assuming all browsers end up supporting it. It would get us past the impasse of webkit not supporting `is`, while also allowing composition of behaviors from multiple custom attributes.

I currently use `is` extensively, but always have to ship the polyfill for webkit. I would happily refactor as custom attributes and drop that polyfill.

@FirefoxDevTools I believe angular has had something like this since Angular v2. Haven't used Angular in a while, but I remember it being very useful.

@FirefoxDevTools e.g. something like adding a material design ripple effect to any element, without having to wrap it in another element just for this effect.

https://material.angular.dev/components/ripple/overview

Angular Material

UI component infrastructure and Material Design components for Angular web applications.

Angular Material
@FirefoxDevTools yes! I’ve been excited about this for a little while now. @cferdinandi and I were just talking about your example case of enhancing a form with extra validation and async submission
@FirefoxDevTools tooltips would be a great use case for this
@FirefoxDevTools I always liked the idea of <my-custom-form is="form"> but that's not going to happen. I never really understood what the reasoning against it was, but that's OK: the question now is, does this approach seem more like it'll be accepted? You say here that it could be a way of "subclassing" elements (as "is" was), which I think is a good idea; will this get rejected for similar reasons, or does it avoid the problems that were flagged with "is"?
@sil Wait, I think you meant `<form is="my-custom-form">`?!
@tomayac I did. d'oh. it's late in the year :)
@FirefoxDevTools 1) I greatly appreciate your subtitles for times when I don't want to play audio. An actual written post would be even better. 😇
2) Some discussion of this (https://github.com/w3c/tpac2025-breakouts/issues/46) has mentioned that custom attributes would need to include a hyphen like custom elements, and then no new standardized attributes could ever include a hyphen. This might conflict with DOM localization (https://github.com/w3c/tpac2025-breakouts/issues/67), whose slides (https://docs.google.com/presentation/d/1ON2yeocyDSVr8r0cg8ZlhgpFfsvloznq1pJqYSADJs8/edit?slide=id.g39906124d40_0_22#slide=id.g39906124d40_0_22) mention a `msg-[param]` attribute format for filling in translated messages.

@FirefoxDevTools @jaffathecake

That t-shirt looks great on you, Jake. Fab! Love it.

@FirefoxDevTools I would love to drop Stimulus in favor of Custom Attributes.