#1070: Scoped Custom Element Registries

Visit on Github.

Opened Mar 18, 2025

こんにちは TAG-さん!

I'm requesting a TAG review of Scoped Custom Element Registries.

This is a proposal allows for multiple custom element definitions for a single tag name to exist within a page. This is accomplished by allowing user code to create multiple custom element registries and associate them with shadow roots that function as scopes for element creation and custom element definitions. Potentially custom elements created within a scope use the registry for that scope to perform upgrades. Changes to Document, Element, ShadowRoot, and HTMLTemplateElement APIs provide the surface area of this feature.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • Previous early design review, if any: N/A
  • Relevant time constraints or deadlines: WebKit seems to have a complete implementation and so may well be shipping soon.
  • The group where the work on this specification is currently being done: WHATWG
  • The group where standardization of this work is intended to be done (if different from the current group):
  • Major unresolved issues with or opposition to this specification: I don't think there are any.
  • This work is being funded by: Apple

Discussions

Log in to see TAG-private discussions.

Discussed Apr 14, 2025 (See Github)

Lola: A way for devs to create custom elements, without having conflicts. The proposal is to do with scopes on custom elements registry. Instead of creating a new scope relying on what's already there. Also think its encapsulation methods are good. If they learn about ??? can they learn about the internals of the application? In the explainer, they mentioned, think to note: when you look up a custom element in a registry at creation time, it is possible that registry could move, then the contetx of the elements change, so using new elements when you expect it to me, and they said it is rare so I'm wondering how they know it is rare.

Dan: In general be cautious on security boundary, like MDN warns on this. Shadow DOM is tool for encapsulation. Iframe may be a better tool if for security ??? You can get to it from the Shadow DOM but not get to it from the global. It feels okay and not loosening. Hard to review this because the explainer is a bit out of date on what webkit proposed. How much of that is meant to apply to current is a question. Elements can be upgraded to custom elements with registry. Once it is initialised it is fixed. How they are done seems robust. Creating with registry A, then moving to shadow B... The proposal is equipped to handle that. There are performance questions aroudn that e.g., does every element need a pointer to the registry? Special cases where you set a bit, where an element is moved to another scope and whether it remembers that. Gecko and Chromium folks mentioned that makes sense. Reasonable to ask the documentation around it should be updated.

Lola: Webkit has the updates as an issue and not a doc. Going to issue to understand what applies to the explainer. Agree with Dan's suggestion to include what is the final thing.

Jeffrey: Apple doesn't do TAG reviews when they want to ship something.

Jeffrey: Lola, work with Christian and DanC to produce a comment?

Lola: Sure. Happy to resolve with Dan.

Dan: Looks good.

Jeffrey: Sounds like consensus to be satisfied with what Lola, Dan, and Christian produce.

Discussed Apr 21, 2025 (See Github)

Dan: Talked about this last week. Group's take is that it's unfortunate that the explainer doesn't capture the current state, but we're happy with the current state. Want Lola's and Christian's review.

Jeffrey: once Lola and Christian are happy shall we approve them to post it?

Christian: Could talk tomorrow, at plenary.

Torgo: Let's cover it at the plenary.

Discussed May 5, 2025 (See Github)

Jeffrey: This one is already closed.