There's a long standing standards issue for this: https://github.com/WICG/webcomponents/issues/909
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.
In You can make up HTML tagsWICG
webcomponents
HTML2014–2026
WICG / webcomponents
webcomponents
Web Components specifications
53Distinct people
96Mentions
0Explicit recommenders
4.5KGitHub stars
What to know before exploring
What it is
Web Components specifications
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- tc39/proposal-signals · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 9:28:18 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year96 dated mentions
Observed mentions: 2014-12-02 17:08:42 UTC to 2026-08-02 06:30:56 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 1 | 0 | 1 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 1 | 1 | 0 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 6 | 4 | 2 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 6 | 1 | 5 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 10 | 1 | 9 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 7 | 0 | 7 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 10 | 2 | 8 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 18 | 0 | 18 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 13 | 3 | 10 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 15 | 0 | 15 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 4 | 0 | 4 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Web Components
Web Components are a new browser feature that provides a standard component model for the Web, consisting of several pieces maintained in different places:
Shadow DOM
Most of the parts are now maintained in DOM Standard, called shadow trees.
Some of the parts are still remained in this repository. See Issue #661 for the progress of upstreaming those parts from the partially out-of-date Shadow DOM document.
Issues against the DOM and HTML Standard.
Issues raised in this repository.
The old issue tracker on W3C bugzilla, which is no longer used.
Custom Elements
Custom elements were upstreamed into the HTML Standard (and bits in the DOM Standard) and are maintained there.
Issues against the DOM and HTML Standard.
Issues raised in this repository.
The old issue tracker on W3C bugzilla, which is no longer used.
HTML Templates
HTML Templates were upstreamed into the HTML Standard and are fully maintained there.
CSS changes
The CSS WG works on CSS Scoping and CSS Shadow Parts, which help dealing with shadow trees with various selectors. Various other parts of CSS and its object model are also impacted by shadow trees and directly worked on in the various CSS specificaions.
Issues against the CSS WG repository.
JSON, CSS, HTML Modules
Successor to the abandoned HTML Imports, allows JSON, CSS, and HTML markup to be requested by a component. HTML Modules Spec work is being incubated upstream in whatwg/html (see PR). For new issues, please file against whatwg/html or here in w3c/webcomponents. See also the HTML Modules explainer, initial proposal, and earlier design ideas.
Issues raised in HTML Standard
Issues raised in this repository. Includes related issues for other potential module-types, such as CSS and JSON.
Old issue tracker includes a few issues filed when the feature was first proposed. Please avoid filing new issues there.
Issues
Please file issues in the most specific repository possible, per the above issue pointers. (It's often not this repository.)
Abandoned features:
HTML Imports
The current issue tracker.
The old issue tracker on W3C bugzilla, which is no longer used.
Note: HTML Modules are intended to replace HTML Imports (see above).
Read the full README on GitHubWhat Hacker News says
15 sourcesweb components need 2 things to be great without external libraries (like lit-html):
- signals, which is currently Stage 1 https://github.com/tc39/proposal-signals
- And this proposal: https://github.com/WICG/webcomponents/issues/1069
which is basically lit-html in the browser
In JSDoc is TypeScriptWeb Components have been in development for 14 years. If you think this is the first discussion of web components, you clearly haven't been paying attention.
All there is to say was said years ago. Today it should be enough to know that, for example, "form associated custom elements cannot be a submit button" issue was opened 6 years ago, in 2019: https://github.com/WICG/webcomponents/issues/814
In 2022 web component group report mentions it in passing: https://w3c.github.io/webcomponents-cg/2022.html#concerns-10
That issue is still open.
Or that web components breaking ARIA was known at least 2019: https://x.com/sarahmei/status/1198069119897047041 and this will not be fixed for another 4-5 years at least.
Imagine if any web framework had issues like that.
That doesn't even begin to cover things like "now every useful spec has to be acut
Read the rest
ely aware of Shadow DOM shenanigans" which delayed any number of specs like scoped CSS etc
> there are a bunch of JS libraries that simplify working with the DOM without resorting to writing fake HTML in JavaScript.
The problem with arbitrary lines is that they are arbitrary: there are no criteria for them except your gut feeling.
You can't rant against "fake HTML" and then turn around and talk about a framework that uses fake JS inside its non-fake HTML.
> Oh, right, observables are the way to go. No, wait, hooks are the right approach. No, wait, signals are definitely the future.
1. It's called evolution. We don't know all the best solutions from the get go.
2. Guess what datastar is using underneath.
Honestly, I don't know if I should continue at this point as you clearly have literally no idea about what you're talking about. You "checked out" from keeping track, you haven't used Datastar or dug into its internals, you call
Read the rest
literal verifiable facts a biased outlook from a framework developer etc.
> Look, the current web standards, and Web Components in particular, aren't perfect. I'm certainly not a fan of some of the design decisions. But they're tools that in conjunction cover a large amount of functionality that modern web frameworks simply ignore or reinvent. This is what I'm saying is a mistake.
Just a few issues with this "tool" that is not perfect, but must be used. Note, this tool has been in development for 14 years this year, and literally none of the "huge bloated frameworks" have this issue. Note that all of these are from the Web Component Working Group report. They themselves wrote about these issues. And these all are issues that "biased" framework developers had been talking for literal years before this report even saw the light of day:
- ARIA is broken. Needs a separate huge JS-only specification that is only now being slowly developed: https://w3c.github.io/webcomponents-cg/2022.html#cross-root-... See a larger description of the issue here: https://nolanlawson.com/2022/11/28/shadow-dom-and-accessibil...
- CSS cascade and theming is broken. Needs several new specs to function, many of them JS-only, some already shipped, some still just being developed: https://w3c.github.io/webcomponents-cg/2022.html#constructab... and https://w3c.github.io/webcomponents-cg/2022.html#css-module-... and https://w3c.github.io/webcomponents-cg/2022.html#css-propert... and https://w3c.github.io/webcomponents-cg/2022.html#custom-css-... and ...
- Document selection is broken https://w3c.github.io/webcomponents-cg/2022.html#composed-se...
- Form participation is broken as it requires additional Javascript per each component to just participate in forms. Buttons inside shadow roots still cannot function as submit buttons: https://w3c.github.io/webcomponents-cg/2022.html#form-associ... and https://github.com/WICG/webcomponents/issues/814
And that's before we get into how they break many other things. Like the fact (that you labeled as biased) that using custom elements-aware APIs leads to a 30% drop in performance.
> `template` is just one building block. You can use it alongside others to do things frameworks can do, except... without a framework! What a concept, I know.
And end up making your own lib/framework in the process. Unless, of course, you want to pretend that all the issues above are nothing to talk about.
> That code is standard HTML with JS in data attributes that does get interpreted at runtime, but it's not an HTML-like DSL that gets parsed and compiled into JavaScript—it is HTML.
That's not JS, and it's not interpreted at runtime. It's painstakingly parsed with regexes, and then certain code is executed based on the result of that parsing.
Somehow "fake HTML" is a no-no, but fake JS? Yeah, go ahead.
Lots of comments in here are about shadow DOM, so let me give my take in one place:
Yes, Lit uses shadow DOM by default (for good reasons, I think!) and yes you can turn it off component-by-component, but that does bring some challenges.
Shadow DOM is most fundamentally just a private branch of the DOM tree for a component's internal DOM details.
Frameworks have this implicitly with DOM defined in a component's template vs passed as children. But that distinction isn't visible to other code, the browser, and CSS. This is both good and bad.
The biggest thing this separate tree gives us is the ability to tell what nodes are "children" - those are the light DOM children. Once you can separate children from internals, you can build slots. Slots are holes in the internals that children get rendered into.
Without something like shadow DOM you c
Read the rest
an't have slots. And without slots you don't have interoperable composition and you don't have viable container elements. You need some way to place children in an element that isn't confused with the element's own DOM.
So to me, before encapsulation and style scoping, interoperable composition is the most important feature, and that's really why Lit defaults to shadow DOM on. Without it we'd need some special `.children` property and Lit's component composition suddenly wouldn't be compatible with everyone else.
But the style encapsulation is often a major pain for developers, especially if they're trying to integrate web components into an existing system with whole-page stylesheets. It's a big blocker to a lot of design systems porting to web components.
That's one reason I proposed something called "Open Styleable Shadow Roots"[1] which would let styles from outer scopes cascade into a shadow root - a way to break open style encapsulation but keep slots. It's been hard convincing browser vendors that this is needed, but I'm holding out hope that it makes progress soon.
[1]: https://github.com/WICG/webcomponents/issues/909
There is a spec issue open for HTML Modules [1] along with a few proposals. The concept needs some motivated champions to see it through. Microsoft has shown some interested in this lately.
There are userland single-file component projects, like my Heximal[2] project. Though Hexiaml specifically doesn't tackle the module format - it requires some kind of HTML Module polyfill.
I don't think the current situation is so bad though. The container format should mostly be irrelevant to consumers of a component. You need to import the component defintion whether that definition is in a .js file or .html file. Once you import it you use it the same.
There should be very few cases where the file format matters. Maybe for use when JS is turned off if HTML-based web components are considered safe to evaluate (their templates might expressive enough
Read the rest
to potentially allow attacks).
[1]: https://github.com/WICG/webcomponents/issues/645
[2]: https://heximal.dev/ (Sorry the site is messed up on mobile. I need to fix it!)
> and it sounds like they want it to contain zero template engines.
The funny thing? No, they want to create a new one: https://github.com/WICG/webcomponents/issues/1069
In "Remove mentions of XSLT from the html spec"After multiple specs had already been pushed through, they finally decided to write down a list of what is still needed.
22 items: https://w3c.github.io/webcomponents-cg/2022.html
In those things like ARIA are not a single spec. It's now close to five different proposals and a huge ARIA Object Model proposal.
Similar thing with Form Associated Controls: it's not one spec. It's a bunch of specs fixing idiotic issues like this: https://github.com/WICG/webcomponents/issues/814
Note: easily half of these only exist because of web components and for web components. Literally nothing else has these issues.
In The time is right for a DOM templating API> True, but they were equally able to propose and deploy alternative solutions and mostly just went along with web components (with exceptions of course).
Safari doesn't have as many engineers (a shame) and definitely doesn't have as many people whose apparent job is just to sit on standards committees and generate specs (like Alex Russel, Justin Fangnani etc.).
They did end up proposing declarative template instantiation in 2017: https://github.com/WICG/webcomponents/blob/gh-pages/proposal... but that mostly went nowhere
In The time is right for a DOM templating APIThe linked proposal has many "features" that would be "needed" if you frame the problem in terms of a "template api", centered around "binding" variables, and what not.
https://github.com/WICG/webcomponents/issues/1069
My proposal only adds one native function with nothing else: no new data types, no new apis.
In The time is right for a DOM templating APIIt's not standard yet. Behavior is implementation-defined and under-specified. A lot of people have used a thing like this[1], but this[2] is on a standards track. In the documentation for the first one, it describes a default "file scope", but really no definition of what a file is. It seems to be referring to a source file pre-build/bundle, but it really just doesn't say. That would belong in the documentation for some framework, not web platform stuff anyway.
The idea of locally scoped styles is reasonably popular. Like vue single-file-components, and n+1 different implementations of "CSS modules". What it really needs though, is standardization. Things like [2] and the upcoming @scope will provide this.
[1]: https://github.com/css-modules/css-modules/blob/master/docs/...
[2]: https://github.com/WICG/webcomponents/blob/gh-pages
Read the rest
Refer to example 4 in the CSS Scoping specification:
> It will not select #three (no slot attribute) nor #four (only direct children of a shadow host can be assigned to a slot).
— https://drafts.csswg.org/css-scoping/#example-7cc70c2d
I’m talking about the #four case.
Alternatively, refer to the issue that was opened in the web components issue tracker here:
> > you can only select a direct item within the slot
> That is by design. See #331 for details.
> We don't have a plan to support an arbitrary selector for ::slotted.
— https://github.com/WICG/webcomponents/issues/594#issuecommen...
> “Web components” aren’t really a thing
This is an empty nitpick. The people writing the specs call them web components, the people implementing them call them web components, the people writing them call them web components. There is nothing wrong with
Read the rest
calling them web components.
> I assume that you’re talking about custom elements with shadow roots here.
You don’t have to assume anything. I explicitly said that it constructed a shadow DOM.
Those reasons are not ideological and there's a new proposal that doesn't have the downsides of the original spec and enables new use cases discovered since: https://github.com/WICG/webcomponents/issues/1029
Nothing with customizable built-ins would give you what the original commenter asked for
In Customizable HTML SelectDOM Parts + Signals will be an absolute game changer for the web platform.
Then there's a direct line to built-in declarative reactive templating: https://github.com/WICG/webcomponents/issues/1069
In Chrome 133 Supports DOM State-Preserving Move with moveBefore()