I believe we are going right to status=stable when we ship the feature. Currently with ScopedCustomElementRegistry feature flag on, it is passing all WPTs for custom elements, including the ones created specifically for scoped registry work. It's being tested under this virtual test suite: third_party/blink/web_tests/virtual/scoped-custom-element-registry/
Debuggability wise, I agree that it's something valuable and worth exploring given that we can have different constructors under the same element name now. On Tuesday, October 14, 2025 at 6:54:34 AM UTC-7 [email protected] wrote: > Sorry one more question. I see > <https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/platform/runtime_enabled_features.json5;l=4307?q=ScopedCustomElementRegistry%20file:%5C.json5&ss=chromium> > > the feature is still in status=test mode and so the WPTs > <https://wpt.fyi/results/custom-elements/registries?label=master&label=experimental&aligned> > > are still all failing on the experimental bot. Can you share the current > WPT results please? > > If, for whatever reason, you don't end up going right to status=stable on > this feature now, please update the feature to status=experimental to get > test results visible. > > On Tue, Oct 14, 2025 at 9:44 AM Rick Byers <[email protected]> wrote: > >> I'm very happy to see this, looks great! We're slowly getting the web to >> a place where we have real component modularity :-) >> >> I have one question about debuggability below, but since that bit has >> already been approved in Chromestatus it's not blocking. LGTM1 >> >> On Mon, Oct 13, 2025 at 5:00 PM Chromestatus < >> [email protected]> wrote: >> >>> *Contact emails* >>> [email protected], [email protected], [email protected] >>> >>> *Explainer* >>> >>> https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md >>> https://github.com/whatwg/html/issues/10854 >>> >>> *Specification* >>> >>> https://html.spec.whatwg.org/multipage/custom-elements.html#customelementregistry >>> >>> >>> *Summary* >>> This feature allows for multiple custom element definitions for a single >>> tag name to exist within a page to prevent custom element name conflicts >>> when a web app uses libraries from multiple sources. This is achieved by >>> allowing user code to create multiple custom element registries and >>> associate them with tree scopes and elements that function as scoping >>> object for custom element creation/definition/upgrade. >>> >>> *Blink component* >>> Blink>HTML>CustomElements >>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EHTML%3ECustomElements%22> >>> >>> *Web Feature ID* >>> scoped-custom-element-registries >>> <https://webstatus.dev/features/scoped-custom-element-registries> >>> >>> *TAG review* >>> https://github.com/w3ctag/design-reviews/issues/1070 >>> >>> *TAG review status* >>> Issues addressed >>> >>> *Risks* >>> >>> >>> *Interoperability and Compatibility* >>> None >>> >>> *Gecko*: Positive ( >>> https://github.com/mozilla/standards-positions/issues/424) >>> >>> *WebKit*: Shipped/Shipping ( >>> https://developer.apple.com/documentation/safari-release-notes/safari-26-release-notes >>> ) >>> >>> *Web developers*: Positive Scoped custom element registry has been a >>> long-awaited feature from the Web Components Community Group, and the >>> current polyfill that didn't solve the entire problem has 24k+ downloads >>> per week. >>> >>> *Other signals*: >>> >>> *WebView application risks* >>> >>> Does this intent deprecate or change behavior of existing APIs, such >>> that it has potentially high risk for Android WebView-based applications? >>> None >>> >>> >>> *Debuggability* >>> None >> >> >> Are you sure? If I'm trying to debug a web page and trying to understand >> the behavior of <my-foo> elements, might I now get confused due to the >> multiple definitions for the same element name? I played with this a little >> and I guess I can always just rely on commands like $0.constructor to find >> the relevant source. But Firefox has a UI badge and hover action for this: >> >> [image: image.png] >> >> Perhaps the scoped custom element registry makes a UI feature like this >> go from nice-to-have to essential? @Danil Somsikov for his thoughts >> since he reviewed and approved the Debuggability bit for this feature. >> >> >>> *Will this feature be supported on all six Blink platforms (Windows, >>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>> Yes >>> >>> *Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>> Yes >>> >>> https://wpt.fyi/results/custom-elements/registries?label=master&label=experimental&aligned >>> >>> *Flag name on about://flags* >>> None >>> >>> *Finch feature name* >>> ScopedCustomElementRegistry >>> >>> *Rollout plan* >>> Will ship enabled for all users >>> >>> *Requires code in //chrome?* >>> False >>> >>> *Tracking bug* >>> https://issues.chromium.org/issues/40826514 >>> >>> *Estimated milestones* >>> Shipping on desktop 143 >>> Shipping on Android 143 >>> Shipping on WebView 143 >>> >>> *Anticipated spec changes* >>> >>> Open questions about a feature may be a source of future web compat or >>> interop issues. Please list open issues (e.g. links to known github issues >>> in the project for the feature specification) whose resolution may >>> introduce web compat/interop risk (e.g., changing to naming or structure of >>> the API in a non-backward-compatible way). >>> None >>> >>> *Link to entry on the Chrome Platform Status* >>> https://chromestatus.com/feature/5090435261792256?gate=6499099686207488 >>> >>> *Links to previous Intent discussions* >>> Intent to Prototype: >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFqEGhaAi0t1ffJoE8Du9bB2Wwxt6CewJjxz2Y_m9qWuoAa-Ug%40mail.gmail.com >>> >>> >>> This intent message was generated by Chrome Platform Status >>> <https://chromestatus.com>. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68ed6866.050a0220.2a8282.0159.GAE%40google.com >>> >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/68ed6866.050a0220.2a8282.0159.GAE%40google.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/93cbf09b-a19a-41b3-9acb-3ac839bcc80an%40chromium.org.
