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

Oh hey, XSLT 3.0 supports server-side rendering and streaming
transformations. But heck, it's more fun to reinvent stuff! :facepalm:

On Thu, Aug 13, 2020 at 8:58 PM Mason Freed <notifications@github.com>
wrote:

>
>    - 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 <https://github.com/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 were mentioned.
> Reply to this email directly, view it on GitHub
> <https://github.com/whatwg/dom/issues/831#issuecomment-673625206>, or
> unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AAGPM5RVFNSHU5I4GRAJWE3SAQSVLANCNFSM4KRWQB5A>
> .
>


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