Posted by todsacerdoti 12/29/2025
That's the premise behind Lit (using the custom elements api)! I've been using it to build out a project recently and it's quite good, simpler to reason about than the current state of React imo.
It started at google and now is part of OpenJS.
It does! <https://lit.dev/docs/components/shadow-dom/>
By default, Lit renders into shadow DOM. This carries benefits like encapsulation (including the style encapsulation you mention). If you prefer global styles, you can render into light DOM instead with that one-line switch.
However, shadow DOM is required for slotting (composing) components, so typically what I'd recommend for theming is leveraging the array option of each component's styles:
static styles = [themeStyles, componentStyles]
protected createRenderRoot() {
return this;
}
When you need to re-render your component, how does the component know not to replace the child content you rendered, Vs the child content it rendered into the light DOM. That's why the shadow DOM and slots were necessary, because then there's no intermingling of your content Vs the component's
This may not be a problem if you don't intend to compose your components. But if you do you will hit limits quickly
While you can easily turn rendering to shadow DOM off on a per-component basis, that removes the ability to use slots. It only really works for leaf nodes.
Pulling a stylesheet into every component is actually not bad though. Adopted stylesheets allow you to share the same stylesheet instance across all shadow roots, so it's quite fast.
My secondary concern with Lit is the additional complexity of using shadow and light DOM together in long lived React/Angular apps. Adding a new paradigm for 75+ contributors to consider has a high bar for acceptance.
And yes attempting to add a new paradigm for that many people is I am sure quite the task. More political than technical in many ways as well.
Thanks for sharing!
If there's no native semantic tag that fits my purposes, I'd much rather stick to a div or span as appropriate, and identify it with one (or more) classes. That's what classes are for, and always have been for.
Support for custom HTML elements seems more appropriate for things like polyfills for actual official elements, or possibly more complicated things like UX widgets that really make sense conceptually as an interactive object, not just CSS formatting.
Using custom element names as a general practice to replace CSS classes for regular formatting just feels like it creates confusion rather than creating clarity.
<div class=expander>
<button aria-expanded=false>Expand</button>
<!-- Some other stuff here -->
</div>
for (const expander of document.querySelectorAll('.expander')) {
const btn = expander.querySelector('button');
btn.addEventListener('click', () => {
btn.ariaExpanded = 'true';
});
}
Custom elements solve exactly this problem. You can now do:
<expander-elem>
<button aria-expanded=false>Expand</button>
<!-- Some other stuff here -->
</expander-elem>
customElements.define('expander-elem', class extends HTMLElement {
connectedCallback() {
const btn = this.querySelector('button');
btn.addEventListener('click', () => {
btn.ariaExpanded = 'true';
});
}
});
Above code will only work when the Web Component is defined after DOM has parsed; using "defer" or "import" makes your JS file execute after DOM is parsed, you "fixed" the problem without understanding what happened.
I blogged about this long time ago: https://dev.to/dannyengelman/web-component-developers-do-not...
► execute <script> at bottom of file
► execute <script defer>
Both do the same; they execute script after DOM was parsed. When your JS creates GUI you now have to battle FOUCs.
► "import" loads your script async
so it _could_ load before _all_ DOM has parsed... but 9999 out of 10000 scenarios it won't
Simply render your <element> (server-side is fine) and whenever the JavaScript downloads and executes your custom elements will mount and do their thing.
I'm really just pushing back on the idea of using them for CSS formatting purposes of general text and layout instead of classes.
Doing this for syntax highlighting on https://janetdocs.org/ shrank the homepage's .html from from 51kb to 24kb, or 8kb to 6kb compressed (at the time).
If you see an unfamiliar tag that has a reasonably simple name, you simply don't know if it's native or for formatting.
That's confusing. It's taking two categories of things and mixing them so you can't tell them apart.
So now you've got to try to enforce some practice of using hyphens in all tag names that used to be class names, even if they're a single word that has no place for a hyphen?
It's getting even more confusing now, you see? Not less.
Just use classes. That's what they're there for.
You just use it (single word) and style it (CSS) and it works. You don't have to "create" anything.
So nothing's stopping anyone from using single-word elements. There's another comment here defending exactly that:
https://news.ycombinator.com/item?id=46418090
But it's bad practice. Just use classes. It's literally what they are designed for.
But yeah I also do see the confusion part, if a person new to HTML sees these custom tags being used it might think it can create one too and not realize it must contain a dash, and it would still work. So yeah in that sense, indeed it's confusing if you're unfamiliar with it.
But having multiple </div></div></div> at the end of a large block of HTML is also confusing, often resulting in closing too many / too few divs. Having </nav-item></nav-bar></main-header> is much better. So yeah it has it's pros and cons I guess.
If I were going to use them, I'd be inclined to vendor them just to prevent any sort of collision proactively
<donatj-fancy-element>
<donatj-input />
</donatj-fancy-element>> You are allowed to just make up elements as long as their names contain a hyphen. Apart from the 8 existing tags listed at the link, no HTML tags contain a hyphen and none ever will. The spec even has <math-α> and <emotion-> as examples of allowed names. You are allowed to make up attributes on an autonomous custom element, but for other elements (built-in or extended) you should only make up data-* attributes. I make heavy use of this on my blog to make writing HTML and CSS nicer and avoid meaningless div-soup. ↩
(HN filtered out a "face with heart eyes" emoji from the second example.)
What makes this awesome is that no future version of HTML can make your custom component stop working; it's supported down at the "bare metal" level.
I wrote an article [0] a couple years ago about how and why this came to be.
0: https://levelup.gitconnected.com/getting-started-with-web-co...
<!DOCTYPE html>
<html
xmlns="http://www.w3.org/1999/xhtml"
xmlns:ns1="mynamespace"
xmlns:ns2="yournamespace"
<body>
<CustomElement>Hello</CustomElement><!-- Custom element in the XHTML namespace -->
<ns1:CustomElement>Hello</ns1:CustomElement>
<ns2:CustomElement>Hello</ns2:CustomElement>
<style type="text/css">
@namespace ns1 "mynamespace";
@namespace ns2 "yournamespace";
CustomElement {
color:green;
}
ns1|CustomElement {
color:red;
}
ns2|CustomElement {
color:blue;
}</body>
</html>
``` <pre><code class="janet">(<special>defn</special> <symb>bench</symb> <str>`Feed bench a wrapped func and int, receive int for time in ns`</str> [<symb>thunk</symb> <symb>times</symb>] (<special>def</special> <symb>start</symb> (<built-in>os/clock</built-in> <keyword>:cputime</keyword> <keyword>:tuple</keyword>)) ```
The article states that anything with a dash is guaranteed not to be and another commenter here shared their strategy that involved a naming convention like <x-special>, <x-symb>, etc. Perhaps substituting x for j would make sense and alleviate the concern of possible future clashes with web standards
The goal is to make content readable by anything. As more users access information through systems like ChatGPT instead of visiting websites directly, content that isn’t easily interpreted by AI crawlers risks becoming effectively invisible.