Re: [whatwg/dom] Declarative Shadow DOM (#510)

@rniwa 

I think @robdodson did a very good comment on what I think the shadowroot is for: and that is your first route: as a macro syntax parser.

A very good concrete use case for this is the ability now for web components that uses shadowDOM is to generate the <shadowroot> tag from the server side, as the initial structure of the shadowDOM of a custom element. The idea here is that any web component that uses a shadowDOM will render its first look, and "stamping" the output of that render inside the <shadowroot>. That's why you can have this...

```
<custom-a>
  <shadowroot>
     Hello <slot></slot>!
  </shadowroot>
  World
</custom-a>

<custom-a>
  <shadowroot>
     Hi <slot></slot>!
  </shadowroot>
  TJ
</custom-a>
```

This just means that the `custom-a` tag has two different shadowroot, because in the server, the generated shadowDOM rendered two different DOM (maybe because of an attribute or some flag). 
The shadowroot automatically puts it as the shadow-root of the custom-element without the need or help of JS. This is very essential if we are vying for a progressive enhancement enabled site that uses shadowDOM.

------

As for having a shadowroot tag to define a custom-element's shadowDOM, this should be relegated to JS only because of the customElements.define API. And besides, it also begs the question, how do you load the definition file of custom-element? If everyone is pulling away from html imports, then how can we define a custom-element without pasting all custom-elements used in all HTML files that will use it?

So I guess, the main use-case of the shadowroot is the first route, not the second one.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/510#issuecomment-333619184