Thomas Broyer · Dec 1

Side note: thanks a lot for the captions! ❤️

Ryan Townsend · Dec 2

I love building custom elements but quickly end up with a deep DOM when keeping them small and nesting, also you often have to code with this nesting specifically in mind.

Alastair Coote · Dec 1

I like the idea in general but I’m curious how it would pair with SSR. Lack of support for that was a big bugbear with Custom Elements and while we’ve arrived at a solution there I’m not sure how you’d ever do it for attributes. (maybe it just doesn’t and we accept that fact upfront!)

Richard Groß · Dec 2

Before this feature I'd like declarative fetching of custom elements. The browser loads <my-element> only when it discovers it in the dom. Eliminate all the custom-built loaders with web standards. Maybe something for importmap 'my-element': 'http://' or a new attribute on the script tag 'on-demand'

claas · Dec 1

What is the differentiation to data attributes?

Stephen Belovarich · Dec 1

YES!

☔ Jim Schofield 🌼 · Dec 2

How does multiple custom attributes work? Does order matter?

Stefan Matei · Dec 1

Yes!

Passle ☭ · Dec 1

Yes! But it'd almost certainly need some kind of scoping, left a comment: github.com/WICG/webcomp...

naugtur · Dec 2

Re: controversies around messing with DOM classes - the method for registering a new attribute could accept a declaration that you want to create an implicit subclass. I'd be eternally grateful if implicit subclassing worked such that all children of that node would also only use the subclass.

Nathan Knowler · Dec 1

Big yes here. I do think the complexity of now needing to deal with multiple cooks working on a single element needs something more powerful the order it was called in JS. We need a cascade for defining (custom) elements and attributes. knowler.dev/blog/declara...

Michael G · Dec 2

I would like to extend svg <path> with generator attributes. Like <path star-radius="10" star-count="5" /> to generate a start shape in the d attribute. Or a boolean operation attribute for a <g> to emulate the behaviour we know from Figma and Sketch.

Scott Jehl · Dec 1

Yes! When I first learned about web components, the "is" attribute made the most sense for how I'd use them most of the time. I still think that, but because Webkit won't implement it, I've gotten used to workarounds. Custom attributes seem as good as "is" (and maybe better?). Would love to see it.

Datastar CEO · Dec 1

I literally wrote Datastar because this kind of option is only available in data-* attributes if you want a spec compliant way to do this. Look at what we've been able to do given the limitations of that spec. Please reach out if you want a whole lot of old man ranting at clouds www.data-star.dev

jeremAIas · Dec 1

I really like this as an enhanced way to handle and distribute attribute behavior on Custom Elements. I wouldn't open this to existing element classes honestly.

Gordon · Dec 1

Yes please! This would give the DOM the equivalent of an Entity-Component System, allowing us to compose complex behavior from simple attributes. See aframe.io for an example of how far you can push this idea.

Christian "Schepp" Schaefer · Dec 1

I like the idea. But why not go all in and open this mechanic for arbitrary CSS selectors? Then we could get lifecycle hooks for any element that we wish.

easrng  · Dec 1

I don't think this should be related to attribute nodes at all and yeah I think the prop versions should be exposed on the HTMLElement prototype (or maybe Element, would this work on SVG or MathML elements?) since that's what frameworks expect

Pier · Dec 1

YES