Re: [WICG/webcomponents] Scoped Custom Element Registry: Moving elements with shadow roots between documents (#907)

@annevk thanks for the quick feedback, few notes:

> Where you mention "moving", that's actually three operations: remove and insert, whereby insert adopts and invokes the adoptedCallback for custom elements so they can adjust to the new document.

Yes, moving connected elements between documents or inserting an element created from another document, which, as a result, kick off the adopting routine.

> I don't really understand where Safari would throw today (and if it's only Safari, is that a bug in other browsers or a bug in Safari not following the standard?).

I was using safari as a reference, but all browsers are throwing a similar error when doing number 2. Here is a simple example:

```js
    class Foo extends iframe.contentWindow.HTMLElement {}
    iframe.contentWindow.customElements.define('x-foo', Foo);
    // moving declaration to another global registry (which doesn't fail but cause other errors later on)
    customElements.define('x-foo', Foo);
    const elm = document.createElement('x-foo'); // throws because of number 4 invariant violation 
```

There are the errors that you can see today:

* Safari: `NotSupportedError: A newly constructed custom element belongs to a wrong document`
* Chrome: `DOMException: Failed to construct 'CustomElement': The result must be in the same document`
* FF: `DOMException: Operation is not supported`

> And yeah, changing the registry upon adoption is an option, though I'm not sure it should be a setter as that would give much more opportunities for changing it than are warranted by the use case.

I have raised other use-cases in the past, e.g.: switching the template used to populate the shadow root could also require different entries in the registry, which is only possible if the registry is interchangeable. I believe the original proposal from @justinfagnani allows that (it only access the registry when needed). And this new use-case is just another reason for having the setter in place.

Another use-case is the integration with Declarative Shadow DOM. If you want to reuse the markup (no attaching a new shadow), you must have a way to link it to a registry to get those elements upgraded (cc. @mfreed7)

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/907#issuecomment-725002959