Posted by zigzag312 1/19/2026
Browsers create ANY tag with at least one dash as a *Custom Element*
They come in TWO flavours, and since they ARE HTMLElement, can be used for layout AND styling with CSS.
The official names are:
► UNdefined Custom Elements (the article calls these "CSS Web Components")
- shadowDOM optional with Declarative ShadowDOM
- shadowDOM optional
- A new Element, or an UPGRADED existing UNdefined Custom Element
### Good to know about UNDEFINED Custom Elements:
* Absolutely NO JavaScript required, it is only HTML and CSS
* This is STANDARD behaviour in all browsers for nearly a DECADE now: Chrome (2016) Safari (2017) FireFox (2018)
* The W3C HTML Validator accepts ALL <tag-name> Custom Elements with a dash as HTMLElement. It does not accept <tagname> (no dash), those are HTMLUnknownElement
* Custom Elements do not inherit the standard [hidden] behaviour; so you have to add that behaviour yourself in your stylesheet.
* Same for DIVs display:block. You have to set the display property on these Custom Elements yourself. (You will forget this 20 times, then you never make the mistake again)
* The :defined pseudo selector targets standard HTML tags and JavaScript defined Custom Elements
* Thus :not(:defined) targets the UNdefined Custom Elements; again... they are still valid HTMLElement so CSS applies like any element
* <you-are-not-bound-to-one-dash>
* Declarative ShadowDOM <template shadowrootmode="open"> creates the same UNdefined Custom Elements WITH a shadowDOM
* The Custom Elements JavaScript API upgrades UNdefined Custom Elements TO defined Custom Elements.
* You can't UNdefine defined Custom Elements
* You can't REMOVE a set shadowRoot
* for now, only Safari supports multiple custom element registries (duplicating Custom Element names)
----
Why?
► Try to find that closing </div> in a long HTML page. </tag-name> is always just there.
► Built a UI that doesn't FOUC, and UPGRADE it lazy-loaded with more logic and interactivity... you can not do this with technologies that CREATE HTML AFTER DOM was parsed.
Custom Elements/Web Components ARE HTML; Frameworks CREATE HTML
We will forever call Custom Elements: Web Components, and vice versa...
And since that would drive us to <div>, I don't see any value in <div class="swim-lanes"> over <swim-lanes>.
Section-relative headings were briefly part of the spec but quickly got removed. As it stands, I would not consider any block of HTML with an <hX> element portable.
[0] https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
It’s more than just an aesthetic preference
But if you’re not really using web components it’s harmless but it’s a bit odd and pointless.
If the underlying premise of your point was entirely independent of web components you’ve done pretty poor job of communicating it.
So you actually do that? Use custom elements without web components instead of using classes? Are you using in something like react with custom elements foregoing type safety to avoid a div element? Or is this just in plain HTML? How many custom elements does your typical web project have?
Or are you fixating on an irrelevant technicality to make an irrelevant point?
The article is literally about not using web components. FTA:
> What would happen if we took the ideas of HTML Web Components and skipped all the JavaScript? [...] Okay great, we styled some HTML nested inside a custom element.
Let’s not pretend like your original point here was they were barely using features of web components correctly, like the parent of this thread was clearly implying.
1. Specificity - swim-line.buttons vs .swin-lines.buttons vs .buttons.swim-lanes. 2. Future pathing - Maybe you don't need a Web Component today, but you might need one tomorrow. 3. Cleaner - <swim-lane /> is just better than <div class="swim-lane" />
:where() gives you zero specificity.
> Future pathing
Sounds like premature optimization. And I say this as someone who has been using custom elements and web components in production since 2016. In fact one of my products offers WCs for our customers:
https://docs.wavekit.app/web-components-wavekit-audio/
> Cleaner
Debatable. Personally I find it cleaner to simply rely on CSS to solve something rather a combination of CSS, JS, and some custom markup.
2. One person's "premature optimization" is someone else's "this was literally something I dealt with this week."
3. This method relies on CSS and HTML, just as any other styling solution would.
Also by using a custom element instead of a class, you're saying this isn't anything else other than what I say it is.
It's not a <section class="swim-lanes">, it's not a <form class="swim-lanes">, it's not a <blockquote class="swim-lanes">, it's a <swim-lanes>.
If you make something only a class, people end up misusing it in odd places.