Re: [WICG/webcomponents] Interaction between imperative slotting and declarative shadow DOM (Issue #967)

> My impression had been that declarative shadow’s use cases were tied up with some notion of producing/taking a “snapshot” which would likely not be maintainable without some kind of generative tooling (e.g. build tools if static or runtime libraries that don’t permit naive string concatenation if dynamic SSR). Since the concern expressed here seems to regard ergonomics, it made me wonder if there are additional motivating use cases where authors would be writing declarative shadows directly?
> 
> (Idea seems fine to me, just trying to get a sense of how much this is meant to be an “author feature” vs (metaphorically) “html bytecode”).

I’m also curious about the use case. Mixing imperative slot assignment with declarative shadow dom, on its face, sounds at least a little odd. If tooling is doing the SSR work, perhaps the generated HTML can just use normal declarative slot assignment? I.e. assign values to the `<slot name=foo>` and `<div id=light-child slot=foo>` to slot in the correct content?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/WICG/webcomponents/issues/967#issuecomment-1270868309

You are receiving this because you are subscribed to this thread.

Message ID: <WICG/webcomponents/issues/967/1270868309@github.com>