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

Initial thought is that this is great for SSR/SSG (already noted as primary motivation) and also acknowledging this isn't necessarily meant to be hand-coded which again aligns with SSR. 

In regards to [Ionic](https://ionicframework.com/), I think this would be a big win as it'd help us reduce/remove JS that converts a component's flat dom tree styled with scoped css, into a shadow root with encapsulated css once the JS kicks in. 

Concerns:
- Is it safe to say the solution would not have a noticeable flicker between the time the declarative SD is painted and the component's constructor is called?
- Will there be performance issues when there's a large list of items, and each item also includes a many child elements with shadow dom? When stress testing this scenario you can see some noticeable differences between a solution using adopted stylesheets, and one inlining style tags into each shadow root (especially on low-end mobile devices which Ionic is targeted for). 
- It'd be pretty easy for devs to explode the size of their html in comparison to traditional html/css. Maybe I'm overthinking it, but what's largely unknown right now is how shared styles could even be possible, but if not, does that also add to the problems that adopted stylesheets should be solving?
- Is it possible to avoid any additional JS checking the existence of a shadow root? Basically I'd like to avoid any new logic in the constructor if possible.
- From what I can see, it seems a significant challenge is how styles are handled, especially around reusing styles. Curious if solving declarative adopted stylesheets should come first.

Overall I'm excited to see this discussion and absolutely can see how it'll benefit Ionic's use-case.



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