Repository navigation
Scoped custom element registries #364
Description
This GitHub issue is for collecting web developer signals for Scoped custom element registries.
The CustomElementRegistry() constructor creates a new custom element registry that's separate from the global window.customElements registry. Creating more than one registry is useful for multiple custom elements that have the same tag name to coexist.
Browser support
- Chrome 146 (Mar 10, 2026)
- Chrome Android 146 (Mar 10, 2026)
- Edge 146 (Mar 13, 2026)
- Firefox: not supported
- Firefox for Android: not supported
- Safari 26 (Sep 15, 2025)
- Safari on iOS 26 (Sep 15, 2025)
Give us feedback
If you're pressed for time, but you want this feature to be available in all browsers, please give this issue a thumbs up 👍 reaction.
However, a much better guide for us is to know how you'd use this feature, and what you're having to do in the meantime. This helps us judge the priority versus other features.
Copy the template below in a comment, and add the details that matter to you.
## What I want to do with this feature
<!-- Add your specific use-cases, even if they seem obvious to you. -->
## What I'm having to do in the meantime
<!--
Are you having to use another feature instead, a polyfill, or is it blocking you completely?
Why are the alternatives worse than using this feature?
-->All comments are expected to adhere to the Code of Conduct.
Learn more
You can learn more about this feature here:
Activity
wkillerud commentedon Dec 12, 2025
What I want to do with this feature
We're running a micro frontend architecture with parts of the page composed from different teams' apps at runtime. The parts are independently deployed, and isolated today using a declarative shadow DOM boundary.
We also have a shared design system with a web components base. Since every part of the micro frontend shares the global custom element registry, to update the design system when there are breaking changes requires a huge coordination effort that scoped custom element registries would solve.
What I'm having to do in the meantime
We try our best to avoid breaking changes, and so far have taken the coordination cost the few times we do have breaking changes.
We have considered versioning through different custom element names (
my-component-2).benjamind commentedon Feb 24, 2026
What I want to do with this feature
I have the same use case as above at a cross organizational level at Adobe. It's a major headache not having Scoped Custom Element Registries.
But also another use case within a single application that can create dependencies in multiple different versions of a design system within the same app for reasons of reproducibility (consistent reproduction of an old ux even though a new version is available).
What I'm having to do in the meantime
It's blocking us completely in the cross org context in some cases. We do have some janky workarounds for limited subsets of components where we rewrite tag names at registration time, but due to transitive dependencies this limits the possible component usage in the micro frontends being vended by teams.
Kai-Richardson commentedon Apr 8, 2026
This is shipping as experimental in Firefox 150: https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Releases/150