Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Scoped registry] Clarify relationship with shadow roots #965

Open
wants to merge 2 commits into
base: gh-pages
Choose a base branch
from
Open

[Scoped registry] Clarify relationship with shadow roots #965

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d8cad1f
Clarify relationship between scoped registries and shadow roots
nolanlawson Aug 10, 2022
52e210b
tweak language
nolanlawson Aug 10, 2022
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 19 additions & 0 deletions proposals/Scoped-Custom-Element-Registries.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -60,6 +60,8 @@ registry.define('other-element', OtherElement);

Definitions in this registry do not apply to the main document, and vice-versa. The registry must contain definitions for all elements used.

Note that, in the above example, `<other-element>` is scoped to the shadow root inside of `<my-element>`. So `<other-element>` is defined within the scoped registry, not `<my-element>`.

Once a registry and scope are created, element creation associated with the scope will use that registry to look up custom element definitions:

```js
Expand Down Expand Up @@ -119,6 +121,23 @@ As a result, it must limit constructors by default to only looking up registrati

This poses a limitation for authors trying to use the constructor to create new elements associated to scoped registries but not registered as global. More flexibility can be analyzed post MVP, for now, a user-land abstraction can help by keeping track of the constructor and its respective registry.

### Note on light DOM custom elements

Custom elements that use light DOM (i.e. that don't call `this.attachShadow()`) may be scoped, but they must be scoped within a shadow root. For example:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a bit confusing as there's no difference in defining elements in a scoped registry, regardless of whether they do or don't use shadow DOM. This seems to be blurring the language between what scope an element is defined in vs whether the element can have its own scope for its own definitions.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added this section to answer a question that may pop into people's heads (it certainly popped into mine), which is: "Wait, this proposal doesn't work for light-DOM-using web components?"

I'm trying to demonstrate that light-DOM-using components are perfectly compatible with this proposal, although maybe there's a better way to phrase this.


```html
<body>
<shadow-element>
#shadow-root (registry=myCustomRegistry)
<light-element>
<div>Light DOM</div>
</light-element>
</shadow-element>
</body>
```

In the above example, `<light-element>` is scoped within the shadow root of its containing `<shadow-element>`, whereas `<shadow-element>` is defined at the global document level.
Copy link

@sashafirsov sashafirsov Aug 10, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we reflect that scope could be more flexible and tied not just to shadowRoot?

There is a scenario when light-element would have declarative custom element definition inside which would be logical to scope to the parent (or somehow named scope) instead whole page.

<body>
  <light-element>
    #light-root (registry=myCustomRegistry)
      <definition tag="custom-element">...</definition><!-- syntax is not clear as of now -->
      <custom-element>
        <div>Light DOM</div>
      </custom-element>
  </light-element>
</body>

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand this. Declarative custom element definitions do not exist yet, and there's no such thing as a light-root.

If <light-element> wants its own scope it'll have to programmatically create one and ensure that an elements it create use scoped instantiation APIs, which right now are only available on ShadowRoot, though we could conceivably also add them to CustomElementRegistry.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was under the impression that Declarative Shadow DOM was out-of-scope for this proposal... Although there is some reference to it here.

Copy link

@sashafirsov sashafirsov Aug 11, 2022 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Declarative Shadow DOM has its sibling and evolution as Declarative Custom Element which could use shadow but also could live without, both in a baking now, not yet a proposal but already have POCs. Both could have a use for scoped registry as scoped by encapsulation as by namespace( a components library ).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Declarative shadow DOM has nothing to do with declarative custom elements. They are unrelated conceptually, as declarative custom elements would not use declarative shadow DOM, and are at very, very different stages of proposal and implementation.


## API

### CustomElementRegistry
Expand Down