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

@treshugart 
> > And the fact that there is a problem with Shadow DOM and SEO **in general** shouldn't block us from moving forward [with Declarative SD].
>
> Really?!?! If this is a shared view, this is highly concerning. Other communities are actively ignoring - and advocating against using web components - for partly this reason.

So far this is just my personal view. However, I think we may get into some misunderstanding here. I agree that Shadow DOM has serious problems with SEO that should be addressed somehow. But since this is an issue about **Declarative** Shadow DOM, I would like to ask:
 1. Do you agree that **imperative** Shadow DOM used to create elements as you suggested at https://github.com/whatwg/dom/issues/510#issuecomment-340614286 will also cause problems with SEO?
 2. Does the declarative form of it would introduce any new issue that was already covered via imperative usage?

I think we could focus here to introduce a new feature; useful for a lot of other reasons; make it no worse than imperative in terms of SEO; keep SEO in mind to hopefully improve it a little bit. But I don't think our goal here is to solve all SEO problems with Web Components through Declarative Shadow DOM.

For that, we could create a separate issue.

----
Speaking of [examples](https://github.com/whatwg/dom/issues/510#issuecomment-340614286).


> It's not clear to me what happens if React updates content in the `<shadowroot>`. For example, when that component re-renders if the name is changed, it will update the content in the shadow root (but only the text node where the name is). **Will this reflect in the real shadow root?**

Given we don't have native support for data binding with `{}` yet (https://github.com/whatwg/dom/issues/150), and even here we had an idea to make `<shadowroot>` element inert after it was parsed and executed (somewhat like `<script>`), I'd rather stick to the second sample.

My naive answer here would be, either

1. Once `<shadowroot>` was parsed, any change to its content will be ignored, 
    then React or any other framework/library could:
    - disallow data binding in `<shadowroot>` (as for `<script>`?),
    - provide a sugar that aliases `.attachShadow +  .shadowRoot`
or
2. We treat `<shadowroot>` as an alias to `parent_div_element.shadowRoot

----

The second one looks pretty safe to me.

If you have JS, SD, and DSD all is good, If you have JS you can somewhat polyfill SD and DSD.
If you don't have JS, but agent supports DSD, you can SSR as expected.

If you want to improve the order for the browser that does not understand Shadow DOM  but still used scoped styles for ones that do, you can achieve it today, w/o declarative SD, by just by moving content to the light DOM.
```
  <div>
    #shadowroot
      <style>{`:host { border: 1px solid black; }`}</style>
      <slot name="greeting">Hello</slot> <slot name="name"/>
    #/shadowroot

    <span slot="greeting">Hola</span>
    <span slot="name">Tomek</span>
  </div>
```
Or if you want to SSR it for the browsers w/o JS, that does not implement Declarative SD yet, you can do the `<shadowroot>` + SD polyfill job by yourself (scoping styles)

I do agree that's problematic. But I think we cannot create such a perfect spec, that will work as desired even in agents that do not implement it ;)

-- 
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-341204802