Re: [WICG/webcomponents] [scoped-registries] Interaction with declarative shadow DOM (#914)

> The issue is of the order. In the case of a partial hydration, is it true that all element definitions come in top-down order in all use cases?

For any chain of nested scoped registry using shadow roots, this is necessarily true. We cannot know what class to use for a name ahead of it.

> As in, is it really okay that all ancestor custom elements need to be upgraded in order for any descendant custom element to be upgraded?

"Is it ok" is an interesting question... With imperative only APIs, there's no other practical ordering possible - the parent has to be created before it creates it's own shadow root to have any children to upgrade. With a new way to have deeply nested shadow roots exist before instantiation we may find use cases where we want to upgrade out of order as an optimization. That seems like something that can be pretty transparently added with declarative registries like @Jamesernator has sketched out. We can reserve the space for this in the HTML attribute:

```html
<template shadowroot="open" shadowrootregistry="">
```

means a null registry that has to be added by script.

```html
<template shadowroot="open" shadowrootregistry="foo">
```

would utilize some registry-registry system so roots can be associated with registries in arbitrary order.

-- 
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/914#issuecomment-799865823