Re: [w3ctag/design-reviews] Declarative Shadow DOM (#494)

Thanks for kicking off this review!

So your question seems to be why Shadow DOM is needed in SSR/no-JS content? I.e. there is a [section](https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#-motivation) of the explainer that details why people want No-JS, but you're asking why they need Shadow DOM with that?

If so, I think the main reason would be that for people using Web Components, they have custom elements that use Shadow DOM. Those components assume the style encapsulation of Shadow DOM, and have stylesheets built accordingly. If those sites are to be SSR'd, and if there is no way to stream out the composed page including the Shadow DOM, then the SSR library would have to do significant work to essentially re-write the entire page in terms of just light-DOM. On the other hand, if a declarative Shadow DOM primitive existed, a simple call to getInnerHTML() would retrieve the entire SSR content that should be streamed to the client. That would be less work on the server, and also on the client, since that composed page could be re-used as-is once the components are hydrated. No need to wipe out the declarative content and re-build it.

The above paragraph is addressed to the SSR and no-JS-user cases, because the goal there is to deliver pixel-correct output via declarative content. The search engine indexing case is a bit different, and as you point out, the "interesting" content is likely slotted in from the light-DOM. But in the discussions I've had with developers, they seem concerned that there is a risk of not properly representing the content to crawlers if the entire shadow DOM is missing.

LMK if that answers your questions!

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/494#issuecomment-621376543