Revamped Scoped Custom Element Registries

[annevk]

https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Scoped-Custom-Element-Registries.md is a good proposal, but it ties the functionality too much to shadow roots. This is Ryosuke and I's proposed improvement attempting to account for feedback given in various Web Components issues on this topic: https://github.com/WICG/webcomponents/issues?q=is%3Aissue+label%3A%22scoped+custom+element+registry%22.

First, the IDL, illustrating the new members:

interface CustomElementRegistry {
  constructor();

  ...
  undefined initialize((Element or ShadowRoot) root);
};

partial interface Document {
  [CEReactions, NewObject] Element createElement(DOMString localName, optional (DOMString or ElementCreationOptions) options = {});
  [CEReactions, NewObject] Element createElementNS(DOMString? namespace, DOMString qualifiedName, optional (DOMString or ElementCreationOptions) options = {});
  [CEReactions, NewObject] Node importNode(Node node, optional (boolean or ImportNodeOptions) options = false);
}

dictionary ElementCreationOptions {
  CustomElementRegistry customElementRegistry;
}

dictionary ImportNodeOptions {
  CustomElementRegistry customElementRegistry;
  selfOnly = false;
}

partial interface Element {
  readonly attribute CustomElementRegistry? customElementRegistry;
};

dictionary ShadowRootInit { // used by Element.prototype.attachShadow
  ...
  CustomElementRegistry customElementRegistry;
};

partial interface DocumentOrShadowRoot {
  readonly attribute CustomElementRegistry? customElementRegistry;
};

partial interface HTMLTemplateElement {
  [CEReactions] attribute DOMString shadowRootCustomElementRegistry;
}

Here’s a summary of how the proposal evolved:

• CustomElementRegistry still gains a constructor.
• ShadowRoot still supports a CustomElementRegistry, exposed through a customElementRegistry getter.
  • It seems important for the shadow root to be able to be independent from its host in terms of registries.
  • Interaction with declarative shadow DOM WICG/webcomponents#914 has a proposal for declarative shadow trees to be able to disable inheriting from the global registry. This adopts that with the shadowrootcustomelements attribute, which is reflected as a string for forward compatibility.
  • ElementInternals gains initializeShadowRoot() CustomElementRegistry gains initialize() so a declarative shadow root (or any element) can have its CustomElementRegistry set (when it’s null).
  • The attachShadow() member is now called customElementRegistry for consistency.
• Element should support an associated CustomElementRegistry, exposed through a customElementRegistry getter. This impacts elements created through innerHTML and future such methods, such as setHTMLUnsafe(). This will allow using non-global CustomElementRegistry outside of shadow roots.
  • setHTMLUnsafe() in the future could maybe also set its own CustomElementRegistry. Given the ergonomics of that it makes sense to expose it directly on Element as well.
• document.createElement(), document.createElementNS(), and document.importNode() are updated to account for registries.

I’ll create specification PRs as well to allow for review of the processing model changes. We believe this resolves the remaining issues with the latest iteration of the initial proposal.

I'd like to briefly go over this in the December 19 WHATNOT meeting and will also be available then to answer any questions. Marking agenda+ therefore.

cc @rniwa @justinfagnani @whatwg/components

---

Minor issue tracker:

• Instead of inventing a new createElement() we should attempt to reuse the existing one on document (with a new customElements member) as we're not quite ready to reinvent how to best do element-creation.
• Should initializeSubtree() perform upgrades in the connected case? (If yes, it should probably also update the scoped document set.) (No.)
• Is there a better name for initializeSubtree()? (Also consider the names already exposed on this object.) Just initialize.
• importNode() is better after all as we need a document anyway. So we should go with a document.importNode(node, { subtree, customElements }) overload.

[thepassle]

So to createElement from a scoped registry, inside a custom element with a shadowroot, you would now have to do:

this.shadowRoot.customElements.createElement('my-el');

Is that correct?

[EisenbergEffect]

Will the global customElements also get a cloneSubtree() method and will this also support built-ins? Essentially, I'm looking for a consistent way to clone templates/fragments with different scopes. So, I'd like to be able to do something like this:

function cloneInScope(src: DocumentFragment, scope: Document | ShadowRoot | Element = document) {
  const registry = scope.customElements ?? globalThis.customElements;
  return registry.cloneSubtree(src);
}

Assuming the above, then at first glance, this proposal looks like it will enable all my scenarios.

[rniwa]

@EisenbergEffect : Yes, cloneSubtree method would be exposed on all registries including the global one. And indeed one of the design constraints we had was to allow a consistent way of creating an element regardless of the registry being used.

[rniwa]

So to createElement from a scoped registry, inside a custom element with a shadowroot, you would now have to do:

this.shadowRoot.customElements.createElement('my-el');

Is that correct?

Yes although a more convenient way is to use whatever node you already have in the shadow tree and do:

node.customElements.createElement('my-el');

[thepassle]

Right so from “inside” a custom element you could either do this.customElements or this.shadowRoot.customElements? To give some context, at ING (bank) we make heavy use of the current scoped registries polyfill and @open-wc/scoped-elements so this wil likely be something we need to address in our codebases, since we currently use this.shadowRoot.createElement. I dont think thats a huge problem though.

Additionally, I think the addition of allowing a registry for a node is a good addition 👍

[matthewp]

Why happens in this scenario?

<outer-element>
  <template shadowrootmode="open">
    <inner-element></inner-element>
  </template>
<outer-element>

<inner-element></inner-element>

Assuming that there are different definitions for inner-element in the light DOM vs the outer-element's template. Let's assume that inner-element gets defined before outer-element.

[rniwa]

@matthewp : in that scenario, all the elements will use the global registry since there is nothing on template or any other element to indicate it should use a scoped registry.

[matthewp]

@rniwa Thanks, that was my suspicion. That seems like a show-stopper to me. Can we add something to template or somewhere else to prevent this problem?

[rniwa]

@rniwa Thanks, that was my suspicion. That seems like a show-stopper to me. Can we add something to template or somewhere else to prevent this problem?

In the proposal @annevk made above, there is shadowrootcustomelements content attribute you can add on template to indicate that a declarative shadow DOM will use a scoped custom element registry.