attachShadow default custom element registry

[ja-y-son]

What is the issue with the DOM Standard?

When calling attachShadow without specified custom element registry, is the new shadow root supposed to inherit host's custom element registry or use the global registry?

From the first step in DOM spec:
"Let registry be this’s custom element registry."
It sounds like we are expecting the shadow root to inherit the host's custom element registry.

However, from this webkit issue, it sounds like this should not be the expected behavior and global registry should be used by default.

Looking at the current implementation in webkit (20623.1.7.19.1), the behavior aligns with the spec and inherits the host's custom element registry instead of the global one.

const scopedRegistry = new CustomElementRegistry();
const scopedElement = document.createElement('div', {customElementRegistry: scopedRegistry});
const shadowRoot = element.attachShadow({mode: 'closed'});
shadowRoot.customElementRegistry === scopedRegistry     // true
shadowRoot.customElementRegistry === customElements   // false

Would like to clarify the spec and the expected behavior.

[ja-y-son]

cc: @annevk @rniwa

[ja-y-son]

FWIW, in the current WPT, it seems like there was intention to make sure attach shadow use global registry by default, but it's passing because the shadow host also happens to be using global registry.

[justinfagnani]

I think the spec here is wrong.

There is no correlation between the scope a custom element is defined in, and the scope it uses for it's own shadow root.

Most element classes today are authored to use the global registry and they import their dependencies assuming that they are self-registering into the global registry. It is entirely possible to define one of these elements into a scoped registry, and it should work fine. This would be true if the element's shadow DOM continues to use the global registry where it's dependencies are defined. It would not always be true if the element's shadow DOM inherits the scope it was defined in, which is out of its control.

[annevk]

Before scoped registries it would also inherit the registry. So I think it makes sense to stick with that model.

[annevk]

Note by the way that

test(() => {
    const registry = new CustomElementRegistry;
    const host = document.body.appendChild(document.createElement('div', {customElementRegistry: registry}));
    const shadowRoot = host.attachShadow({mode: 'closed', customElementRegistry: null});
    assert_equals(shadowRoot.customElementRegistry, registry);
}, 'attachShadow() should use the shadow host\'s registry when customElementRegistry is null');

also tests this. The main thing that's missing I think is a declarative shadow root setup as the WebKit bug hints at there being an issue there.

[justinfagnani]

Before scoped registries it would also inherit the registry. So I think it makes sense to stick with that model.

Before scoped registries it uses the global registry. It just so happens that both the host and it's shadow DOM use the same registry because there is only one.

If the shadow root inherits the host's registry is will break elements.

[keithamus]

@justinfagnani can you cite some examples where inheriting the hosts registry will break elements? Is this using the polyfill or does this break developers' expectations in other ways?

[justinfagnani]

Here's an example that works with today's Safari that would break if it were updated to follow the spec (If I'm understanding "Let registry be this’s custom element registry." correctly):

https://lit.dev/playground/#gist=eeb4a426e405b6642063fa5f78da6e63

class ElementC extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({mode: 'open'});
    this.shadowRoot.innerHTML = `<h3>Element C</h3>`;
  }
}
customElements.define('x-c', ElementC);

export class ElementB extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({mode: 'open'});
    this.shadowRoot.innerHTML = `
      <h2>Element B</h2>
      <x-c></x-c>`;
  }
}
customElements.define('x-b', ElementB);

const registryA = new CustomElementRegistry();
registryA.define('my-x-b', ElementB);

export class ElementA extends HTMLElement {
  constructor() {
    super();
    this.attachShadow({mode: 'open', customElementRegistry: registryA});
    this.shadowRoot.innerHTML = `
      <h1>Element A</h1>
      <my-x-b></my-x-b>`;
  }
}
customElements.define('x-a', ElementA);

If the <my-x-b> instance's shadow root inherits its registry, it'll be this registryA, which doesn't have <x-c> defined in it, so <my-x-b> will be broken.

You can't change the registry that ElementB uses from under it. It's written to use the global registry, so it must continue to use the global registry. This is one of the first changes we made to my proposal after discussing it at the Toronto face-to-face. I proposed inheriting and I believe Ryosuke pointed out that you can't change the registry for an element without possibly breaking it.

[annevk]

When I run that in Safari I don't see "Element C" in the Result tab. Doesn't that mean that it's "broken"? I don't really understand though how this is supposed to work though. The my-x-b instance's custom element registry will be registryA. How would the browser figure out that the actual registry is something else?

I guess what you're saying is that it would be easier for migration if we continued to use the global registry and then elements that did not want to use the global registry would specify an explicit registry in their attachShadow() call. But is that going to be the right answer long term as well?

[justinfagnani]

@annevk

Huh, in STP 216 I see:

Not seeing "Element C" would mean that it's broken.

I don't really understand though how this is supposed to work though. The my-x-b instance's custom element registry will be registryA.

I'm saying that it should not be registryA and that it should be the global registry.

How would the browser figure out that the actual registry is something else?

No registry is set in attachShadow() so it should use the global registry.

I guess what you're saying is that it would be easier for migration if we continued to use the global registry and then elements that did not want to use the global registry would specify an explicit registry in their attachShadow() call. But is that going to be the right answer long term as well?

Yes, it's always the right answer. The outer scope (the host's scope) should not change the inside scope. That's an implementation detail of the element that the outer scope is messing with. An element should always be able to rely on its registry.

[sorvell]

But is that going to be the right answer long term as well?

I don't see any reason to assume there should be a connection between the registries used in different scopes. Previously, there was only ever 1 registry so all existing custom elements work with this assumption. While it's true that any scope registry user has to opt-in to using them (x-a in this case), with the current behavior, I can't safely use an existing custom element in my scoped registry DOM without knowing and registering all of its dependencies.

This seems very cumbersome. In the example, x-b was created in the world before custom registries so it assumes it can use the x-c from the global registry (the ElementC class).

All I should have to do to use x-b in x-as registry is registryA.define('my-x-b', ElementB). However, because x-b will also use x-a's registry, I must also do registryA.define('x-c', ElementC). This breaks encapsulation by polluting registryA.

[sorvell]

To ensure it can be used safely within a scoped registry any existing custom element would have to be modified to this:

this.attachShadow({mode: ..., customElementRegistry: window.customElements})

[ja-y-son]

I'm also seeing the same output as Justin running the above example (Release 221 (WebKit 20622.1.15.19.2))

With Justin's snippet, it seems like a bug on webkit if the original intention was to follow the spec:

const aElement = document.createElement('x-a')
aElement.shadowRoot.querySelector('my-x-b').customElementRegistry === registryA      // true
aElement.shadowRoot.querySelector('my-x-b').shadowRoot.customElementRegistry === window.customElements    // true

Regardless, I think shadow root not inheriting host's registry is a better option to ensure the backward compatibility and the isolation between scopes.