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

> > * Allowing serialization and deserialization of DOM that includes Shadow DOM. Currently, there is no way to get innerHTML including shadow roots, because there is no declarative way to represent it.
> 
> Can you give an example of why this is needed? e.g. if you're using a custom element, doesn't the custom element know how to re-create its own Shadow DOM, meaning the light DOM is sufficient?

Two reasons, I think:
 - For SSR, you want an "easy" way to convert your **already-hydrated** server-side DOM tree, with custom elements and their Shadow DOM content, to HTML. Each custom element could be required to provide its own serialization routine for its Shadow DOM, but it would be more convenient to just write rootDiv.getInnerHTML() to get the entire page.
 - For any UA "save as HTML file" operation to be able to save actual HTML, you need a way to represent shadow roots. See [this comment](https://github.com/w3c/webcomponents/issues/788#issuecomment-575871982), for example. MHTML [has a way](https://docs.google.com/document/d/1FvmYUC0S0BkdkR7wZsg0hLdKc_qjGnGahBwwa0CdnHE/edit#heading=h.50kx2q8iy9rf) to secretly represent the shadow roots, but why shouldn't that just be normal HTML? The syntax for MHTML's shadow root is actually quite close to this declarative Shadow DOM proposal.

> > * CSS developers, interested in using the style-scoping feature of Shadow DOM, do not want to use (or their design system prohibits) Javascript.
> 
> This makes me somewhat uneasy. My understanding isn't that style scoping isn't a "feature" of Shadow DOM that you can choose to use in isolation, but rather a part of the encapsulation guarantees that Shadow DOM provide, in order to ensure that components using Shadow DOM can be safely re-used in any context.
> 
> This encapsulation has consequences for things like:
> 
> * label association and other IDREF-based associations (yes, we are working on script-based solutions to these problems but in a no-JS context the associations would still fail),
> * user scripts and customisations like extensions (ChromeVox classic had to be retired, for example, because it was impossible to make it work with Shadow DOM, due to the event path being obscured)
> * testing tools - many testing tools have been reworked to be able to traverse Shadow DOM via open shadow roots, but it requires significant engineering effort.
> 
> Do you know to what extent Shadow DOM is being used in this way? Have I misunderstood?

It's a good question. For right now, there **is no other style scoping mechanism** provided by the web platform. If you want style scoping, you either roll it yourself, or you use Shadow DOM. I agree that Shadow DOM includes much more than just style encapsulation, and as you mentioned, that has other consequences. But for now, it's all we have. There is a project underway to propose and spec a light-DOM style scoping mechanism, but that is likely a ways off. We haven't even published that proposal yet. In the meantime, Shadow DOM is the style scoping mechanism we have. I would argue that the consequences you list above are ones that we should try to fix anyway. They represent shortcomings of tooling w.r.t. Shadow DOM in general. No?


> > Even if they want to use Web Components, they can't, because SSR is seen as a hard requirement.
> 
> To what extent is this based on a (possibly outdated) perception of how search engines work, vs a requirement for rapid rendering on the client?
> 
> Sorry for all the meta-discussion, but I'd really like to fully understand the context for this feature before trying to form a solid opinion on the design.

It is possible that part of this requirement is due to out-dated perceptions of search engines. However:
 1. this perception seems to be quite widely held
 2. search engine behavior is:
    a. Not well published, on purpose
    b. Hugely important to commerce on the web.

Primarily for reason <span>#</span>2 above, I can completely understand the ongoing hard requirement to use SSR. Even knowing what I know, if I was building an external site, I would likely reach the same conclusion.


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