Re: [w3c/webcomponents] Scoped Custom Element Registries (#716)

> Scopes are completely defined when an element is created.

This sounds the most important principle in the proposal, to understand the behaviors.  It's a new `ownerDocument`, so to say.

comments
-----
- We already have a global registry on `window`, not on `document`.  Do we also want a registry which is associated to `document` such that any descendant shadow roots is not affected?

- Related, for `Element.prototype.scope`, if the element is from the global registry, why `document` but not `window`?

- Why `CustomElementRegistry` inherits from another `CustomElementRegistry`? I'd guess users may want to use elements registered to its parent scope, but rarely want to use sibling or descendant ones.  Why not this inheritance (custom elements name lookup chain) be specified via `ShadowRoot` creation? (e.g. `ShadowRootInit` has `inheritCustomElementRegistry: true`?)

- For mix-ins, `CustomElementRegistry.prototype.import(registry: CustomElementRegistry)` to import already defined elements? And for not overridden definitions, a newly created element will be given its definition's original scope.

- If global registry contains a definition for `<my-element>`, and if a shadow root contains `<my-element>` as well, it will be upgraded before the definition for scope-local `<my-element>` is given, but as the element is already upgraded, it never gets upgraded to its scoped version.  Later if `<my-element>` is appended after the scoped definition, it becomes a scoped `<my-element>`. This behavior is understandable as well as confusing - will this be better if we have explicit `customElements.upgrade` (https://github.com/w3c/webcomponents/issues/710)?

- Shall we introduce `ShadowRoot.prototype.adoptNode` in addition to `importNode`?

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