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

> > * While we disagree about the benefits and issues associated with streaming support here, I think we've reached somewhat of a consensus that streaming support can be added later, with something like `<template shadowroot=open streaming>`.
> 
> I'm not sure. I certainly don't want to support two different variants of this feature.

Well, I've opted to avoid a streaming solution now, so that I can get [your support](https://github.com/whatwg/dom/issues/510#issuecomment-372224104) for the overall feature. Let's cross the streaming bridge later, once this non-streaming version is done. I will note, however, that there does seem to be significant developer interest in a streaming solution.

> > * As @caridy points out, we've discussed closed shadow root support in the [explainer](https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#existing-declarative-shadow-roots) and in [Issue 871](https://github.com/w3c/webcomponents/issues/871). You are saying that without resolving [Issue 871](https://github.com/w3c/webcomponents/issues/871), you cannot support this declarative Shadow DOM proposal. I understand your concern, and I'd like to solve it. But is the inverse of your statement true? I.e. if we resolve [Issue 871](https://github.com/w3c/webcomponents/issues/871), could you then support declarative Shadow DOM?
> 
> In my view, [w3c/webcomponents#871](https://github.com/w3c/webcomponents/issues/871) is the biggest blocker. I can't definitively say we'd support this proposal yet because I'd like to confirm the performance benefit claims made in the favor of this feature on our end. I'd try to do that sometime soon.

Thanks for looking into it. The [motivation](https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#-motivation) for this feature is primarily to support Server Side Rendering. And as described in the explainer, while performance is **one** of the reasons people use/require SSR, it is definitely not the only reason. For many, SEO is just as important a reason, since not all crawlers support JS, or support it in the same way. So my hope would be that your support for this feature is not gated only on the performance claims being verified.

> 
> > I've just [proposed a fix for Issue 871](https://github.com/w3c/webcomponents/issues/871#issuecomment-672082936), which I will commit to implementing in Chromium immediately, if agreed upon. Please take a look there, and let's get that issue resolved. And then I'm hoping you'll be supportive of this proposal.
> 
> I have to think through the use cases and circle back with my colleagues but on surface that does look like a reasonable solution to me, and it does indeed remove the biggest blocker of this proposal in my view. Again, I'd like to confirm the performance benefit claims if there is any on my end and need to circle back with some of my colleagues who are more skeptical of this feature in general to definitely say whether can support this feature or not.

Great, thanks!

-- 
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/831#issuecomment-673625206