- From: Ben <notifications@github.com>
- Date: Wed, 03 Feb 2021 01:07:08 -0800
- To: whatwg/dom <dom@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <whatwg/dom/issues/831/772351643@github.com>
I think my point is that you are previously server side rendering light DOM moving to use DSD today is a downgrade and has some issues. The arguments around ancient browsers are all true but I am not talking about ancient browsers, I am talking about browsers that don't support it today. It may be a long time before adoption of DSD by browsers reaches enough to make it worthwhile to DSD. On the point of CSS grid, it is possible to [progressive enhance with `@supports`](https://codepen.io/kaleidawave/pen/BaQoNpE). Here there is no way to branch that (unless the server did something based on user agent). If a new JS or CSS feature comes out then it can be slowly adopted will fallback using their branch mechanisms. But making the light DOM to DSD SSR switch today has to adopted as one. And I understand x not working because it requires new web api is okay. But this is something as simple as navbar rendering incorrect / not at all when it would have worked on light DOM. I don't think there is any way to maintain backwards compatibility if you want to use shadow DOM and SSR. And I think as soon as browser adoption of this feature reaches 95% then it shouldn't be an issue. I don't think this is a issue for sites that currently don't render light DOM. And I can see the benefit of SSR in content for a external component rather than sending a empty tag and generating it during hydration. It should be noted that DSD is not a drop in replacement for rendering light DOM WC content (which alot of people are doing atm) -- 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-772351643
Received on Wednesday, 3 February 2021 09:07:20 UTC