On writing the custom elements section for Modern Web Guidance

# The native-first lean was intentional

When I drafted those guides, I was deliberately pushing models toward native HTML and CSS. Nolan describes that section as "discouraging at times"^[1], and I can certainly see why.

Writing these guides, we all had to switch from our default writing-for-humans mindset to a writing-for-agents one; generally speaking, agents lean into abstraction. Ask for a button with a particular set of styles and there's a real chance you get a <my-button> where a styled <button> would do. The guidance aimed to set a higher bar: build a custom element when you need encapsulated state, a scriptable API, or behavior the native element can't express. A different look alone doesn't call for a whole web component.^[2]

# Still a huge web components fangirl

I was a staff engineer on Spectrum Web Components at Adobe and co-founded the PatternFly Elements project at Red Hat^[3] (one of the earliest web-component-based design systems from an enterprise company), so I've been discouraged by the industry's continued push to React-ify everything. If the choice is between a framework and a collection of web components, I'll advocate for web components every time.^[4] I'm also part of both the CSS Working Group and the Web Components Community Group, and a lot of my standards work is collecting the community group's decisions, then presenting and advocating for them in the CSS Working Group.

What I keep running into, in framework libraries and web component libraries alike, is components built for jobs a native element and some CSS would do better: accordions that could be <details> and <summary>, modals that could be <dialog>, menus that could lean on the popover attribute. Those wrappers usually ship more JavaScript and lose some accessibility along the way. The people using them often can't see that, because they work with the component's API and never touch the HTML underneath.

The question that section asks is one I'd put to a React or Svelte component too: does this need to exist, or is the platform already doing the work?

As a first stab at turning that into a principle: web components are a good option when the project doesn't already use a different component framework, and the pattern needs at least one of these:

• Nontrivial markup beyond what a native element gives you.
• Interactivity. Custom elements have reliable lifecycle callbacks (connectedCallback, disconnectedCallback), which beats wiring up querySelectorAll and a MutationObserver to notice when elements come and go.

# Common ground

Nolan reads the line about design systems, embeddable widgets, and self-contained UI as a faint nod.^[5] For me, those are the main use case. A design system primitive shared across apps built in different frameworks, or a widget dropped into a page you don't control, is where web components earn their place, and his own <emoji-picker> example fits right in that category.

I also agree with his closing point that web components have done a lot to explain the platform.^[6] Guidance that tells an agent to reach for <details>, <dialog>, or popover first is pointing at features that web component ideas helped shape, through work like Open UI. By proving what features and APIs developers wanted, web components directly influenced the speed and maturity of the specifications.

# More to say

There's a lot more in the post that I'd like to come back to: the case for reuse when a rewrite costs one prompt, and the long-standing gaps he lists around server-side rendering, sharing stylesheets, and accessibility across shadow roots.^[7] Those gaps are where I spend a lot of my standards time, and I agree that having agents write the code doesn't make those issues any less urgent.

So, the TL;DR: the native-first lean in the guidance was deliberate, an attempt to convince AI to reach for the platform before abstracting. Web components still have a clear job in that picture: shared design system primitives, embeddable widgets, and anything that has to work across frameworks. Where a native element and some CSS can do the work, I'd rather an agent reach for that first, whatever component model the project uses. To me, both approaches push work back to the platform.

Thank you to Nolan for writing this. He has spent years making the case for web components in public, and it shows in how carefully he weighs both sides here, including the parts he says were hard to write. His posts are some of the most thoughtful writing on web components out there, and I'm glad to be part of the conversation.

And thank you for following along as I think this through. If you see it differently, or you've watched agents handle components in ways I haven't, I'd love to hear about it. Tag me on Mastodon at @castastrophe@front-end.social.