In the past I've seen this one:
https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
Perhaps there are more recent versions.
I liked the spirit of the proposal, but never studied it.
In Templating in HTMLWICG
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
10 sourcesNo one blocked it. If you're referring to HTML Imports, the problem with them is that they didn't integrate with JS modules. There's a new HTML modules proposal [1], and with JS import assertions and CSS and JSON modules landing [2], HTML modules are probably not far behind.
[1]: https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
[2]: https://web.dev/css-module-scripts/
In Templating in HTMLI believe this is the current iteration:
https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
You can learn more of the history here:
https://www.w3.org/2020/10/TPAC/parts_and_template_instantia...
https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
In Show HN: I made React with a faster Virtual DOMI remember seeing this a few years ago: https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
In Show HN: I made React with a faster Virtual DOMAh, I didn't realize this wasn't solved -- a quick search turns up:
- https://github.com/WICG/webcomponents/issues/788
- https://github.com/w3c/DOM-Parsing/issues/58
- https://github.com/w3ctag/design-reviews/issues/494
- https://web.dev/declarative-shadow-dom
In pre-render they seem to have started in this direction extremely recently:
https://github.com/prerender/prerender/pull/731/files
I don't use prerender so I can't definitively speak to it being solved and hiccup-free, but I think that limitation is going to go away in the future.
In Shoelace: A Web Component Kitthis is called an html module: https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
In CSS's !important was added because of laws about font size for some textAsk HN: What are some recommended patterns when using Web Components?
The MDN Web docs [0] are useful to understand what are custom elements, the shadow DOM, or templates and slots. But as someone starting with web components and front-end stuff in general, I was wondering about the recommended approaches/design patterns when building more complex apps ?
For instance, how should components communicate with each other? By using a parent element systematically, firing up events from child nodes, then calling children methods from the parent node? Is this the equivalent of the "props down, events up" pattern in React for instance [1]?
Regarding the life-cycle, is there any reason to use the `constructor()` instead of the `connectedCallback()` for init code?
Another one that seems to have sparked some debate [2]: how to work with custom elements that need to interact with their children? Should I use `setTimeou
Read the rest
t()` to wait for the DOM to be parsed [3], should I use mutation observers, or should I fire up an event from the children to notify its parent when it is ready to be used?
These are just a couple questions that came up when reading about this, but I am curious about general best practices when building front-end apps using web components.
[0] https://developer.mozilla.org/en-US/docs/Web/Web_Components
[1] https://jasonformat.com/props-down-events-up/
[2] https://github.com/WICG/webcomponents/issues/809
[3] https://stackoverflow.com/questions/58354531/custom-elements-connectedcallback-wai…
> Members of a standards body are accountable for their actions.
Yes, yes they are. This also means that none of the browser implementors should be on the steering committee by your criteria.
> Endorsing a standard, then undermining it
Let's see about that endorsement and "undermining":
--- start quote ---
Now I'm going to re-iterate that Apple objects to extending subclasses of HTMLElement using is= as currently spec'ed for various reasons we've stated in the past and this feature won't be supported in WebKit.
...
I'll note that we've vocally and repeatedly objected to having is=, and in fact, stated publicly that we won't implement this feature, but somehow the WG kept it in the spec. I wouldn't call that a consensus. We extremely reluctantly agreed to keep it in the spec until it gets removed at risk later.
...
we're against subclassin
Read the rest
g subclasses of HTMLElement (e.g. HTMLInputElement, etc...) for various reasons, so WebKit isn't going to support this feature anyway. Extension of builtin elements are much better served with mixins.
...
And this entire comment: https://github.com/WICG/webcomponents/issues/509#issuecommen...
--- end quote ---
So did Safari endorse Web Components? Yes. And they still do. See, for example, Template Instantiation Proposal (among many other things): https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
Did Safari ever support `is=`? No.
Let's see their endorsement again:
--- start quote ---
The thing is, Apple has been objecting to this feature from the get go, and the only reason it remains in the spec is because Google kept objecting to it being removed from the spec.
The fact of matter is, we only agreed to keep it in the spec to wait until the feature becomes at-risk at CR stage so that it can be removed.
--- end quote ---
I would also recommend you read this comment on the whole process and "obligation to implement" and other things (it's not from Apple): https://github.com/WICG/webcomponents/issues/509#issuecommen...
> and you can draw a straight line from Apple’s overwhelming institutional arrogance to Safari being the “new IE”.
There's definitely a PR manager in Chrome who gets a bonus every time this line is repeated. See breaking the web forward: https://www.quirksmode.org/blog/archives/2021/08/breaking_th...
Webkit is not committed to fully implementing the HTML Living Standard, or more precisely, they are committed to killing off the parts they don't like by declining to implement them. They point-blank refuse to implement Customized Built-in Elements, for example, and in such (unusually, for the context) vehement, uncompromising, and unconstructive language¹ that I can only surmise some Apple apparatchik's fragile ego would be irreparably shattered by even contemplating an amendment of this position.
Thanks to such attitudes, Safari remains the "new IE", the problem browser for which developers must find workarounds.
(1) e.g. https://github.com/WICG/webcomponents/issues/509 and other forums besides
In New WebKit features in Safari 15.4