Scoped Custom Element Registries

[justinfagnani]

Since #488 is closed, I thought I'd open up a new issue to discuss a relatively specific proposal I have for Scoped Custom Element Registries.

Scoped Custom Element Definitions

Overview

Scoped Custom Element definitions is an oft-requested feature of Web Components. The global registry is a possible source of name collisions that may arise from coincidence, or from an app trying to define multiple versions of the same element, or from more advanced scenarios like registering mocks during tests, or a component explicitly replacing an element definition for its scope.

Since the key DOM creation APIs are global, scoping definitions is tricky because we'd need a mechanism to determine which scope to use. But if we offer scoped versions of these APIs the problem is tractable. This requires that DOM creation code is upgraded to use the new scoped APIs, something that hopefully could be done in template libraries and frameworks.

This proposal adds the ability to construct CustomElementRegistrys and chain them in order to inherit custom element definitions. It uses ShadowRoot as a scope for definitions. ShadowRoot can be associated with a CustomElementRegistry when created and gains element creation methods, like createElement. When new elements are created within a ShadowRoot, that ShadowRoot's registry is used to Custom Element upgrades.

API Changes

CustomElementRegistry

• CustomElementRegistry(parent?: CustomElementRegistry)

  CustomElementRegistry is constructible, and able to inherit from a parent registry.

  New definitions added to a registry are not visible to the parent, and mask any registrations with the same name defined in the parent so that definitions can be overridden.

• CustomElementRegistry.prototype.get(name: string)

  get() now returns the closest constructor defined for a tag name in a chain of registries.

• CustomElementRegistry.prototype.getRegistry(name: string)

  Returns the closest registry in which a tag name is defined.

ShadowRoot

ShadowRoots are already the scoping boundary for DOM and CSS, so it's natural to be the scope for custom elements. ShadowRoot needs a CustomElementRegistry and the DOM creation APIs that current exist on document.

• customElements: CustomElementRegistry

  The CustomElementRegistry the ShadowRoot uses, set on attachShadowRoot().

• createElement(), createElementNS() These methods create new elements using the CustomElementRegistry of the ShadowRoot.

• importNode() Imports a node into the document that owns the ShadowRoot, using the CustomElementRegistry of the ShadowRoot.

  This enables cloning a template into multiple scopes to use different custom element definitions.

Element

New properties:

• Element.prototype.scope: Document | ShadowRoot Elements have DOM creation APIs, like innerHTML, so they need a reference to their scope. Elements expose this with a scope property. One difference between this and getRootNode() is that the scope for an element can never change.

• Element.prototype.attachShadow(init: ShadowRootInit)

  ShadowRootInit adds a new property, customElements, in its options argument which is a CustomElementRegistry.

With a scope, DOM creation APIs like innerHTML and insertAdjacentHTML will use the element's scope's registry to construct new custom elements. Appending or inserting an existing element doesn't use the scope, nor does it change the scope of the appended element. Scopes are completely defined when an element is created.

Example

// x-foo.js is an existing custom element module that registers a class
// as 'x-foo' in the global registry.
import {XFoo} from './x-foo.js';

// Create a new registry that inherits from the global registry
const myRegistry = new CustomElementRegistry(window.customElements);

// Define a trivial subclass of XFoo so that we can register it ourselves
class MyFoo extends XFoo {}

// Register it as `my-foo` locally.
myRegistry.define('my-foo', MyFoo);

class MyElement extends HTMLElement {
  constructor() {
    super();
    // Use the local registry when creating the ShadowRoot
    this.attachShadow({mode: 'open', customElements: myRegistry});

    // Use the scoped element creation APIs to create elements:
    const myFoo = this.shadowRoot.createElement('my-foo');
    this.shadowRoot.appendChild(myFoo);

    // myFoo is now associated with the scope of `this.shadowRoot`, and registy
    // of `myRegistry`. When it creates new DOM, is uses `myRegistry`:
    myFoo.innerHTML = `<my-bar></my-bar>`;
  }
}

Open Issues

• [ ] https://github.com/WICG/webcomponents/issues/914
• [ ] https://github.com/WICG/webcomponents/issues/907
• [ ] https://github.com/WICG/webcomponents/issues/923
• [ ] https://github.com/WICG/webcomponents/issues/1001

Questions

This section is not current. See the open issues list

• What happens to existing upgraded elements when an overriding definition is added to a child registry?

  The simplest answer is that elements are only ever upgraded once, and adding a new definition that's visible in an element's scope will not cause a re-upgrade or prototype change.

• Should classes only be allow to be defined once, across all registries?

  This would preserve the 1-1 relationship between a class and a tag name and the ability to do new MyElement() even if a class is not registered in the global registry.

  It's easy to define a trivial subclass if there's a need to register the same class in different registries or with different names.

• Should registries inherit down the tree-of-trees by default, or only via the parent chain of CustomElementRegistry?

  Inheriting down the DOM tree leads to dynamic-like scoping where definitions can change depending on your position in the tree. Restricting to inheriting in CustomElementRegistry means there's a fixed lookup path.

  • Should the registry of a ShadowRoot be final?
  • Is Element.prototype.scope neccessary?

  It requires all elements to remember where they were created, possibly increasing their memory footprint. Scopes could be dynamically looked up during new DOM creation via the getRootNode() process instead, but this might slow down operations like innerHTML.

• How does this interact with the Template Instantiation proposal?

  With Template Instantiation document.importNode() isn't used to create template instances, but HTMLTemplateElement.prototype.createInstance(). How will that know which scope to use? Should it take a registry or ShadowRoot?

/cc @domenic @rniwa @hayatoito @TakayoshiKochi

[rniwa]

Let's not pile on orthogonal proposals or problems onto this issue. We want to keep this issue focused on scoped custom element registry.

[jarrodek]

I have yet another use case for using scoped registry. I gonna need help to tackle this issue. In our platform multiple applications can work simultaneously in the same document. Applications are coming from both our internal and external developers that builds for the platform. Because of that each application has to be secured by default. When using global registry when one application registers an element this element instantly is available to other applications running in the document. Some of them may operate on private data (either user or customers data). This leads to the decision made by our security team to disable global registry and custom elements altogether (we use proxy object on window). This decision makes WC unusable in our platform and I don't like this idea. So the question here would be how can we make scoping inaccessible from other scripts? Would it be possible to scope a component to a domain for example? So the application A hosted in domain a won't be able to initialize or even detect a component initialized by application B hosted on different sub domain? I guess that would also fix an issue I mentioned in my previous comment. Can anyone have a different idea of how to deal with such problem?

[frank-dspeed]

@jarrodek I am Security Specialist my Self there is a solution we call it iframe read also CSP Content Security Policys

Note that a parent frame has no control over a iframe while the iframe has control over the parent.

[frank-dspeed]

@jarrodek another note about the registry at all maybe not all got it right the registry don't register any element!!!!! It registers Element Definitions I am the creator of a next-generation Frontend Framework that uses only raw ECMA i call it tag-html and here are some examples how customElements is implamented you can also look into the pollyfill from webcomponents

<my-custom-element-that-is-undefined></my-custom-element-that-is-undefined>
<script>
const definition = { connectedCallback() { this.innerHTML = 'Works' } }
const script = document.currentScript
const previousElementSibling = script.previousElementSibling
definition.connectedCallback.call(previousElementSibling)
script.remove()
</script>

Hope that gives you some insights

class ElementDefinition {
    connectedCallback() {
        this.innerHTML = 'Works'
    }
}

customElements.define('parent-is-element-definition',class ParentIsElementDefinition extends HTMLElement {
    connectedCallback() {
        const target = this.previousElementSibling
        ElementDefinition.prototype.connectedCallback.call(target)
    }
})

customElements.define('parent-is-element-definition',class ParentIsElementDefinition extends HTMLElement {
    connectedCallback() {
        const target = this.previousElementSibling
        customElements.get('my-element-version').prototype.connectedCallback.call(target)
    }
})

the conclusion is all your components and data are always accessable via the window object always there is nothing never like private vars only exempt is nativ code from the browser but even that is opensource and can be reviewed via patching the browser.

About the Code

The Code Samples at the top do illustrate how to apply customElement definitions to the object over the original definition one time JS version one time CustomElement version your free to use it as customElements registry replacement under the Apache-2.0 Licence Cheers

Usage

<my-custom-element-that-is-undefined></my-custom-element-that-is-undefined>
<script>function(){ this.innerHTML = 'Works' }.call(document.currentScript.previousElementSibling);document.currentScript.remove();</script>

the content of my-custom-element-that-is-undefined will be "Works"

you can also define like in the second example a parent-is-element element that applys the definition to the element over it

<my-custom-element-that-is-undefined></my-custom-element-that-is-undefined>
<parent-is-element-definition></parent-is-element-definition>

[LarsDenBakker]

At the virtual F2F in march the conclusion was to aim for a slimmed down version of https://github.com/w3c/webcomponents/pull/865:

• No inheritance between registries
• No getDefinitions()
• "newing" the constructor of a custom element will evaluate it in the scope of the global registry.

There was a concern raised by @rniwa about moving elements and it's associated custom element registry between iframes, because the custom element registries are backed by JS and native code. (if I recall correctly).

What's the process for moving forward with this? We need to update the proposal with what's agreed on, can I help with that?

For the iframe part, does there need to be any investigation on the implementors side or do we just need to come up with a proposal on how to deal with this problem?

[snuggs]

@frank-dspeed pardon my ignorance but what is .previousElementSpiebling ?

[caridy]

@LarsDenBakker I sent a PR to @justinfagnani few weeks ago (right after the meeting) with the updates:

https://github.com/justinfagnani/webcomponents/pull/1

I'm waiting for him at this point to look at it, also waiting for him to create the repo for the proposal, so we can start organizing this better now that we have some tentative consensus. I've few cycles to work on this, and to work on the spec as well, we just need to get rolling.

[justinfagnani]

Sorry Carridy, I didn't get a notification for the PR. Looking now.

As for a repo, I haven't seen other proposals in this area get their own repo. Is there precedence or a template for that?

[caridy]

A repo is easier IMO, e.g.:

https://github.com/mfreed7/declarative-shadow-dom

I'm fine either way! just let me know what works better.

[frank-dspeed]

@snuggs

<div></div>
<parent-is-element-definition></parent-is-element-definition>

div is the prevElementSibling of parent-is-element-definition

<div id="instance1"></div>
<parent-is-element-definition></parent-is-element-definition>

<div id="instance2"></div>
<parent-is-element-definition></parent-is-element-definition>

<div></div>
<parent-is-element-definition></parent-is-element-definition>

<custom-name-one></custom-name-one>
<parent-is-element-definition></parent-is-element-definition>

in that scenario i demonstrate the usage of a customElement that does fire a connectedCallback but apply the definition to the element before it

[leobalter]

A repo is easier IMO, e.g.:

https://github.com/mfreed7/declarative-shadow-dom

I'm fine either way! just let me know what works better.

@justinfagnani considering the precedence and also using it as an example, I believe a new repo could be useful.

I'd like to offer my help - along with @caridy - to support this moving forward.

I understand I'm a new comer here, but one of the advantages I estimate is that a new repo would find a better place to prepare everything specific. Even more after a good part of the web components migrated to other specs.

WDYT? I'm looking forward to be of any help here!

[trusktr]

@jarrodek @frank-dspeed

off topic:

> build process of each application this would inevitably lead to name collision and component registration errors For that problem, what I do is my libraries export only classes, then I let the consumer run ```js import {TheClass} from ''the-library" customElement.define('any-name-the-user-wants', TheClass) // alternative API provided by my lib: TheClass.define('any-name') // defined elements. ``` This way the end user has control on the application side instead of the library dictating the name. Lastly, all of my classes come with default names, that the user can opt into: ```js import {TheClass} from ''the-library" TheClass.define() // this registers the element with a default name, f.e. // alternatively register all classes in the whole lib with their default names: import {useDefaultNames} from ''the-library" useDefaultNames() ``` This leaves applications with control. If they have a collision, the specific application can be modified to specify a different name. > Some of them may operate on private data (either user or customers data). This leads to the decision made by our security team to disable global registry and custom elements altogether (we use proxy object on window). As @frank-dspeed said, and as your security team should be saying, you should run entirely separate apps inside iframes. That's how you get security. Plus, an added benefit of this is that it would reduce custom element naming collisions because each iframe has its own registry.

But please, lets not create off-topic conversations, because it makes it more difficult and tedious for spec authors to collaborate on the issue. Your issues are related, but not directly on topic. You can open a new help topic after first asking on StackOverflow and not getting any answers in a reasonable amount of time.

As you may be able to tell, the collaborators are skipping the off-topic comments and attempting to work on the proposal.

Moderators, if you can please mark this (and a couple previous replies) as off-topic, it'll prevent them from showing up in Google search results.

[justinfagnani]

@leobalter glad to hear the offer. I'll create a new repo today.

[justinfagnani]

@leobalter @caridy I created the repo here, just copying the initial text from the PR https://github.com/justinfagnani/scoped-custom-elements

I'll make a PR to this to address the outstanding feedback.

[leobalter]

That's great, @justinfagnani! Thanks!

[rniwa]

A repo is easier IMO, e.g.: https://github.com/mfreed7/declarative-shadow-dom I'm fine either way! just let me know what works better.

@justinfagnani considering the precedence and also using it as an example, I believe a new repo could be useful.

Please, no. We already have this, HTML, and DOM repositories, and various issues and discussion are scattered across all those repositories' issue trackers and PRs. The last thing we want is adding even more repositories and issues and PRs to follow the discussion.

[rniwa]

One thing that's unclear from https://github.com/justinfagnani/scoped-custom-elements is that in which tree(s) existing unknown custom elements are upgraded in define call.

There is another subtle but important aspect. When a shadow root is created without an explicit registry, it must use document's registry. But this is the owner document of the element, not of the global object to which the element's prototype comes from. This is an important point. Because it would mean that if you adopt a custom element C_1 from a document D_A (e.g. template document) to another document D_B, then any nested shadow roots S_N in that custom element C1's shadow roots S_1 would default to the other document D_B's registry, not the original document D_A's.

[leobalter]

One thing that's unclear from https://github.com/justinfagnani/scoped-custom-elements is that in which tree(s) existing unknown custom elements are upgraded in define call.

I believe each registry (customElements or new instances of CustomElementRegistry) will have it's own independent tree (or mapping tree) of element definitions. The trees would be differentiated according to the entity they are associated to. e.g. customElements is always associated to the Document and new registries need to be associated to a ShadowRoot.

FWIW, define should apply definitions this way. The problem goes within the distinction in the shadow root as you already described. Idk yet what would be the best solution here, maybe @justinfagnani and @caridy can help me out on this one.

[rniwa]

One thing that's unclear from https://github.com/justinfagnani/scoped-custom-elements is that in which tree(s) existing unknown custom elements are upgraded in define call.

I believe each registry (customElements or new instances of CustomElementRegistry) will have it's own independent tree (or mapping tree) of element definitions. The trees would be differentiated according to the entity they are associated to. e.g. customElements is always associated to the Document and new registries need to be associated to a ShadowRoot.

FWIW, define should apply definitions this way. The problem goes within the distinction in the shadow root as you already described. Idk yet what would be the best solution here, maybe @justinfagnani and @caridy can help me out on this one.

I'm not sure I follow what you're saying. Multiple ShadowRoot can use a single custom / scoped CustomElementRegistry so it's unclear how it can have its own independent tree. It's more like a list of shadow trees but then the order in which those trees appear becomes a question. Presumably the order by which they're created because they don't necessary have any other well defined order.

[caridy]

@rniwa can you put together some kind of example to showcase the issue? I'm having a hard time understanding the problem.

[rniwa]

const registry = new CustomElementRegistry;

const d1 = document.createElement('div');
d1.attachShadow({mode: 'closed', registry}).innerHTML = '<some-element id="d1s1"></some-element><some-element id="d1s2">';

const d2 = document.createElement('div');
d2.attachShadow({mode: 'closed', registry}).innerHTML = '<some-element id="d2s1">';
const d3 = document.createElement('div');
d3.attachShadow({mode: 'closed', registry}).innerHTML = '<some-element id="d3s1">';

const iframe = document.createElement('iframe');
document.body.append(d2, d1, iframe);
iframe.contentDocument.body.append(d3);

class SomeElement extends HTMLElement {
    constructor() {
        super();
        this.attachShadow({mode: 'closed'}).innerHTML = '<other-element></other-element>';
    }
}
registry.define('some-element', SomeElement);

customElements.define('other-element', class OtherElement extends HTMLElement { });

Now, should d1s1, d1s2, d2s1, and d3s1 be upgraded? If so, in what order? Should other-element in d1s1, d1s2, d2s1, and d3s1's shadow trees be upgraded if so, in what order?

[caridy]

Ok, this is great @rniwa, that clarifies a lot. My intution here is as follow:

1. Today, with the global registry, this example will upgrade 6 elements in the following order:

SomeElement with id=d2s1
SomeElement with id=d1s1
SomeElement with id=d1s2
OtherElement inside SomeElement with id=d2s1
OtherElement inside SomeElement with id=d1s1
OtherElement inside SomeElement with id=d1s2

with SomeElement with id=d3s1 being the only one that is never upgraded since it was inserted inside the iframe.

2. Tomorrow, with the scoped registry, this example will still only 4 elements, in the following order:

SomeElement with id=d2s1
SomeElement with id=d1s1
SomeElement with id=d1s2
SomeElement with id=d3s1 (because it is defined in the scoped registry for `d3`)
OtherElement inside SomeElement with id=d2s1 (updated)
OtherElement inside SomeElement with id=d1s1 (updated)
OtherElement inside SomeElement with id=d1s2 (updated)

Updated: While OtherElement instance inside SomeElement with id=d3s1 is never upgraded because SomeElement's shadow roots is inheriting the registry from the ownerDocument, which is the iframe, and that registry does not have an entry for OtherElement.

I believe your concrete question is about d3s1, and whether or not it should be upgraded due to the fact that it is defined in a scoped registry from the outer window, which is plugged into the iframe while appending the div. But I don't see a reason why not, considering that we don't inherit or use the global registry when a scoped registry is used. Do you see any reason for a scoped registry to not be used by shadow roots attached to elements from different documents?

[rniwa]

While OtherElement instances are never upgraded because all div's shadow roots are using scoped registries.

I don't think this is right. this.attachShadow in SomeElement didn't specify any registry so it should be using the global registry.

If it automatically "inherited" parent shadow tree's registry, then this raises a new question. What happens when SomeElement is instantiated outside of a shadow tree then inserted into another shadow tree with a scoped registry. Note that this is precisely what happens in synchronous element construction case (e.g. by using new) so this behaving differently from the upgrade case is extremely confusing.

In other words, is the shadow tree's custom element registry determined at the time it's attached or is it dynamically determined by the tree structure. In order to have the semantics you described and not have an inconsistency between upgrade and synchronous construction case, we need to do the dynamic determination. But this poses yet another issue about temporarily detaching an element from a shadow tree so it's not great either.

All in all, there is a lot of open questions here.

[frank-dspeed]

i am not sure but i want to say something as i am deep into this stuff since some years.

Out of my View There should be no such customRegistry needed all that the current reg does is calling some hooks. we can archive that with custom conditions and mutation observer in round about 10 short lines of code.

So if one has the need for handling elements with a custom lifecycle Mutation Observer is the way to go it supports all that.

Some none tested code examples out of my head showing all 4 hooks

  const attributesObserver = new MutationObserver(function(mutations, observer) {
    mutations.forEach(function(mutation) {
      if (mutation.type == "attributes") {       
          attributeChangedCallback.apply(mutation.target,[mutation.attributeName, mutation.oldValue mutation.target.getAttribute(mutation.attributeName)])
      }
    });
  });

  const childListObserver = new MutationObserver(function(mutations, observer) {
    mutations.forEach(function(mutation) {
      if (mutation.type === 'childList') {
        mutation.addedNodes.forEach(connectedCallback.apply)
        mutation.removededNodes.forEach(disconnectedCallback.apply)
      }
    });
  });

attributesObserver.observe(el, {
  attributes: true, //configure it to listen to attribute changes
  attributeOldValue: true,
  attributeFilter: ['hidden', 'contenteditable', 'data-par'] // individual listen to attributes.
});

childListObserver.observe(el.parent, { childList: true, subtree: true });  

[caridy]

@rniwa

While OtherElement instances are never upgraded because all div's shadow roots are using scoped registries.

I don't think this is right. this.attachShadow in SomeElement didn't specify any registry so it should be using the global registry.

I think you're right, let me update my comment above to reflect that OtherElement instances for SomeElement inserted in the main window should get upgraded. Can you take a look at my previous comment again?

If it automatically "inherited" parent shadow tree's registry, then this raises a new question. What happens when SomeElement is instantiated outside of a shadow tree then inserted into another shadow tree with a scoped registry. Note that this is precisely what happens in synchronous element construction case (e.g. by using new) so this behaving differently from the upgrade case is extremely confusing.

I was under the impression that we have some previous agreements about these cases: when an element is upgraded inside a shadow root, the lookup will occur at that point, while attachShadow() will have no side effects on the matter other than setting up the registry to be used if provided.

In other words, is the shadow tree's custom element registry determined at the time it's attached or is it dynamically determined by the tree structure. In order to have the semantics you described and not have an inconsistency between upgrade and synchronous construction case, we need to do the dynamic determination. But this poses yet another issue about temporarily detaching an element from a shadow tree so it's not great either.

In the explainer, it is listed as dynamically determined by the tree structure. This opens the door for replacing the registry at any given time, as a possibility, or just replacing the registry when adopted by another document, etc.

About the temporarily detaching an element issue that you mentioned above, can you provide more information? Maybe another example? The way I see it, if an element is upgraded already (dynamically or via sync construction), and that element is temporarily detaching (while moving it around), it should not have any side effects on any element from its shadow root that was already upgraded.

[justinfagnani]

I realize that we don't have an issue specifically covering scoped registries and declarative shadow DOM interaction. I'll open that now. We also have a couple of issues from #895 to be opened.

[justinfagnani]

Added https://github.com/WICG/webcomponents/issues/914

[justinfagnani]

I just oped #923 to specifically discuss upgrade ordering.

[lazka]

In the explainer, it is listed as dynamically determined by the tree structure. This opens the door for replacing the registry at any given time, as a possibility, or just replacing the registry when adopted by another document, etc.

Sorry for the noise, maybe this is obvious, but would this also affect slotted nodes? I would assume the registry not changing when you slot something.

[caridy]

@lazka slotted notes are not affected by the local registry since they belong to a different shadow root or document. Scoped registry only operates on the elements inserted inside the shadow root in question.

[lazka]

Makes sense, thank you!

[trusktr]

I believe it would be better that if someone does something fishy, like moving a scoped custom element from a ShadowRoot to the main Document or another ShadowRoot, an error would be thrown (f.e. DOMException: Scoped custom element does not belong to this Document or ShadowRoot). I do not think that allowing weird patterns is ideal in any language or system in general, if it can be avoided.

Just having scoped registries, even if we can move elements around and end up with same-tag elements with different prototypes, would still be great though. I just believe in helping end users by throwing meaningful errors when they use APIs in ways that we don't want them to.

Because using Scoped Custom Element Registries is an opt-in feature, there is no harm / no breaking change in throwing errors for those weird scenarios, and honestly it will help people by keeping their programs in states that make sense. Errors serve as self-documenting features of a system.

[Jamesernator]

I believe it would be better that if someone does something fishy, like moving a scoped custom element from a ShadowRoot to the main Document or another ShadowRoot, an error would be thrown (f.e. DOMException: Scoped custom element does not belong to this Document or ShadowRoot). I do not think that allowing weird patterns is ideal in any language or system in general, if it can be avoided.

Even if people want to move elements in and out of a shadow root, it could be an option to require using .adoptNode, which would require the element also be defined in the target ShadowRoot/Document (otherwise throw an error for not being defined in scope), this would change the name as needed and also call adoptedCallback on the element which would be a useful signal that it has changed scopes.

[robrez]

We use "portals" which teleport content from one context to another, say document.body for overlays. I expect this may be a common pattern and it would be nice to be able to utilize scoping somehow (probably driven by the original context).

[frank-dspeed]

@robrez scoping for your case is easy simply use MutationObserver on the sections and then upgrade your elements.

[adrianhelvik]

I also think it would make more sense as a CSS proposal.

.tooltip {
  layout-context: root;
}

Or with a wrapper

.wrapper {
  layout-id: 'wrapper';
}

.tooltip {
  layout-context: 'wrapper', root;
}

Or something. Portals are a great solution in frameworks for now, but they solve a styling issue which is better fixed by improving CSS.

[robrez]

Does class resolution involve any kind of bubbling?

For example... say there are two classes, "FancyButton1" and "FancyButton2"...

<body>
  <fancy-button> <!-- FancyButton1 -->
    <some-module>
      #shadowRoot (fancy-button = FancyButton2)
        <fancy-button>
        <some-other-module>
          #shadowRoot
            <fancy-button> <!-- what am I? -->

[bicknellr]

Does class resolution involve any kind of bubbling?

IMO, there shouldn't be any kind of implicit recursive lookup, even just into the global registry. Otherwise, you don't really have control over what's actually in your 'scoped' registry.

I'm less opinionated about whether or not recursive lookup should be possible with an explicit signal - such as passing a 'parent'/'fallback' registry when constructing a new scoped registry - but I don't think that enabling that should be considered a blocker for scoped registries in general. It seems separable enough that it would be ok if scoped custom element registries initially shipped without any recursive lookup at all.

[caridy]

Both of those cases are not part of the MVP. They were at some point, but we settled on a more simpler approach. Either the shadow has a registry associated to it, or it doesn't, in which case it uses the global one.

[robrez]

Yeah, that makes sense. I had a use-case where some-module and some-other-module are kinda related packages such that only some-module uses some-other-module and it was causing me to have some tunnel vision and a bit of distorted view.

Things could probably get quite unreliable if bubbling lookups started happening depending on where you reparented an element that didn't engage in a scoped registration (of its dependencies). I suppose the behavior in this case must be to look at the global registry (otherwise breaking changes start flaring up)

[adrianhelvik]

I think non-bubbling is definitely better. Bubbling lead to a bit of confusion in AngularJS and non-bubbling improves separation. I believe non-bubbling will reduce the cognitive load of working with custom elements.

I think globally scoped custom elements should be available in scoped shadow roots. Registering core UI elements in the global registry would be a productivity boost. But as with anything global it is a footgun. It would also allow more gradual refactoring to scoped registries. I also think it would be a source of confusion if your custom element stopped working after adding scoped custom elements. There would be a lot of StackOverflow questions about it! 😄

I really like how you register local components in Vue, and I think we should take some inspiration from that.

this.attachShadow({
  mode: 'open',
  customElements: {
    MyInput,
    SomeWidget,
  }
})

With PascalCase it is easier to compose multiple custom element collections. If kebab-case is required, you would have to default export an object. Greppability will however improve if kebab-case is required, so I don't have a strong opinion on the matter.

import * as formElements from './elements/formElements.js'
import * as buttons from './elements/buttons.js'

this.attachShadow({
  mode: 'open',
  customElements: {
    ...formElements,
    ...buttons,
  }
})

If there is a need to access or set the CustomElementsRegistry directly (I can't think of a good reason), it could be accessed through ShadowRoot#customElementsRegistry and specified by passing customElementsRegistry to attachShadow with an XOR check for customElements and customElementsRegistry.

[adaliszk]

Soo, this has been open for a while. Does anyone have a polyfill for any of the suggestions? Can we push this or any unregister-way so that native web components would be able to gain HMR capabilities?

Right now, what I can see is that if we hijack the current registry, we could define elements with a hash in them, make a shim for the original name that then pass everything to the hashed version and just continuously re-register with a new hash and re-render.

While it will have some memory-leak issues over time, it would be only really present in the development cycle where we could hit a refresh button every now and then to avoid it creeping too high.

[trusktr]

I also think it would be a source of confusion if your custom element stopped working after adding scoped custom elements. There would be a lot of StackOverflow questions about it! 😄

This is a really good point. Suppose we took this problem to JavaScript. Imagine we have this code:

let foo = 123

function doIt() {
  console.log(foo)
}

It would be surprising and unexpected if writing

let foo = 123

function doIt() {
  let bar = 456
  console.log(foo)
}

suddenly caused the console.log to start outputting undefined because the function scope now has it's own "registry" of variables.

In this same vein, it seems there has to be a fallback lookup. We have some options (Option 3 is my favorite):

1. Specifying a downgrade operation for custom elements might be useful: if a custom element was upgraded to a global class because the local scoped registry didn't have a class defined, but then later the registry gets the class defined, the element can be downgraded before being upgraded to its new class.

2. Any elements already upgraded to a higher-registry's definition, before a scoped registry gets a definition, stay with the original class. Elements inserted after the scoped registry has the definition take on the new definition.

3. Once a scoped registry is live (belongs to a shadowroot that is connected into a document) all higher-registry definitions that aren't contained by the scoped registry have been inherited and all of the scoped registry's definitions become permanent (we can not add new ones). This would require people to think ahead, and to pre-define a scoped registry's definitions prior to making the registry live. Once live, definitions are permanent in the same sense as how we cannot arbitrarily add or remove variables from a function scope.

Option 3 is the "type safe" way to do it: the developer has a higher chance of knowing ahead of time what elements they will use in their program. Everything works as expected (for the most part): no gotchas, unexpected results, or bugs resulting from elements accidentally treated as the wrong type of element, or resulting from upgraded vs not-yet-upgraded elements (one of the banes of custom elements development), etc.

I say "higher chance" because the global registry is still dynamic, and definitions can be added any time after it is already live (it is already live from the start of a web app).

this.attachShadow({
  mode: 'open',
  customElements: {
    MyInput,
    SomeWidget,
  }
})

This is interesting, and enforces type safety. 👍 We pre-define what we'll use, with no surprises, and no difficulties from having to think about pre-upgraded instances.

Having to handle pre-existing property values from pre-upgrade instances with the class fields [[Define]] abominable snowman chasing us makes things extremely difficult. People shouldn't have to think about this sort of thing.

Unfortunately, even with the type safe approach, cloneNode does not construct custom elements, which still poses the pre-upgrade problem for anyone using the cloneNode API (like many DOM template libs do). The worst thing is that not all CE authors even know about the pre-upgrade problem, and their elements are destined to not work in various apps using different techs.

[daKmoR]

Soo, this has been open for a while. Does anyone have a polyfill for any of the suggestions?

we are currently using this https://github.com/webcomponents/polyfills/tree/master/packages/scoped-custom-element-registry

Can we push this or any unregister-way so that native web components would be able to gain HMR capabilities?

you might wanna take a look at https://open-wc.org/docs/development/hot-module-replacement/

Right now, what I can see is that if we hijack the current registry, we could define elements with a hash in them, make a shim for the original name that then pass everything to the hashed version and just continuously re-register with a new hash and re-render.

you mean register not the "actual" component name but my-component-2dfjk43? this is how version of scoped elements was implemented https://www.npmjs.com/package/@open-wc/scoped-elements/v/1.3.3

it sort of works... but

• it's not fully scoped (can be misused and you still have access to the global registry which can result in issues if you move nodes from light to shadow dom or vise versa)
• css selectors do not work
• annoying to use in tests (as tag names are always different)

in version 2 we are now using the scoped custom elements registry linked above

---

@trusktr

This is a really good point. Suppose we took this problem to JavaScript. Imagine we have this code:

let foo = 123

function doIt() {
  console.log(foo)
}

IMHO this is taking the wrong "conclusion". Writing code like this couples your function into a specific location in the code. e.g. you will not be able to move your doIt function into any other file... which is probably fine for JS but we don't wanna have web component that only work if rendered in a specific dom.

e.g. if I define my custom element and it uses a <sub-el> in its shadow dom... it needs to bring that sub-el with it.. don't expect other web components to be available globally

<my-el>
  # shadow-dom
      <sub-el></sub-el>
</my-el>      

We have been using ScopeElements for ~2 years now and explicitly defining ALL web component you use in your shadow dom is absolutely essential. And yes you can still say to grab a specific component from the global registry... but you need to be aware that this component becomes "less shareable".

We specifically added an example for that

https://open-wc.org/docs/development/scoped-elements/#usage

[justinfagnani]

I've had many requests from important partners like Adobe, ING, YouTube, and other Google teams to try to get this proposal moving again. For some potential customers, this issue has been a blocker from adopting custom elements at all. The larger the team/organization using custom elements, the more critical the tag name collision problem becomes.

The current open design questions are:

• [ ] https://github.com/WICG/webcomponents/issues/914
• [ ] https://github.com/WICG/webcomponents/issues/907
• [ ] https://github.com/WICG/webcomponents/issues/923

I'll update the main text of this issue to list these as well so that teams can use this as a tracking issue from the spec side.

[EisenbergEffect]

We at Microsoft are also very, very interested in this and consider it an extremely high priority as well. Let us know how we can help get it moving.

[leobalter]

@EisenbergEffect I believe the issues listed above at https://github.com/WICG/webcomponents/issues/716#issuecomment-1049015966 are still the missing parts, which require feedback on implementation details, IMO.

While my team at Salesforce cannot provide the implementation aspects of it, I'm happy to have engineers from the LWC framework involved if you need more information.

cc @caridy @nolanlawson @pmdartus

[caridy]

@EisenbergEffect we can try to get the ball rolling again. I will be happy to discuss the current open questions with a small group. In our case, we went from "absolutely needing this feature" to "maybe virtualizing the global registry rather than using a local/scoped registry" due to the lack of progress.

[justinfagnani]

We have quite a few major customers, including Google as a whole that need this feature.

I have talked with @mfreed7 about the open issues and when Chrome could prototype this feature to get real implementation feedback on the open questions.

At least for the upgrade ordering question (#923) , it seems like a path forward might be specifying document order upgrades and letting implementations optimize as they can by tracking which shadow roots are associated with which registries to avoid a whole document tree walk.

I think #914 is solvable by requiring top-down upgrade order, and #907 could be informed with implementor feedback.

[EisenbergEffect]

I also talked with @dandclark on our side yesterday. Maybe we can re-infuse this with some energy and move it forward. I'll dig into the issues myself in the next couple of days. @justinfagnani What you are saying above makes good sense to me though.

Additionally, I'd love to hear how folks are solving for their scenarios while waiting for this to land. I have a number of ideas but have been hesitant to implement any of them. @caridy I'd love to hear more about your experience there.