Re: [w3ctag/design-reviews] Declarative Shadow DOM (#494)

> What we'd like to see more consideration of, is can this be designed such that streaming is presumed, and implementations can opt-out? The goal being that a user can write their code once, presuming streaming is available, and get the benefits of a streaming implementation should it be available, but not break should the browser not support streaming. This would be more friendly to progressive enhancement without authors having to develop both streaming and non-streaming versions of their code.

Thanks for the suggestion - this is a great idea! If done right, this would allow implementations that do not wish to shoulder the additional burden of supporting streaming not to do so, while still supporting the more basic non-streaming version, and therefore the feature in general.

> As an example (pure strawman), could there be an async api for fetching the shadowRoot, such that a streaming implementation returns it on the opening tag, and further content may come in later (perhaps another async method to return when a given shadowRoot is fully loaded), and that non-streaming implementations simply don't return the shadowRoot until the close tag (and they always return a fully loaded shadowRoot, or perhaps return an empty shadowRoot and then immediately fill it so all code reacts like streaming is happening).

So right now this proposal does not specify any events for shadowRoot attachment, even in the non-streaming case. We've been trying to keep that problem (the "the [parser finished / children changed](https://github.com/w3c/webcomponents/issues/809) problem") separate from this one, just to avoid hanging this proposal up on finding a solution to that problem. However, I definitely think we should tackle that problem in a general way. Would you be ok if we just made a change here something like this:

---

```html
<template shadowroot="open" do-not-stream>
```

The `do-not-stream` attribute, if present, indicates that the shadow root should only be attached when the parser encounters the closing `</template>` tag, and not before. If this attribute is not present, then the implementation **may or may not** attach the shadow root upon the opening `<template shadowroot>` tag, and begin constructing shadow content in place in the `#shadowroot`, rather than waiting for the closing tag. In other words, the support of "streaming" is an optional feature of the rendering engine, and many not be supported by all engines.

---

With such a definition, and even absent the events being defined, I think this is a very usable API. Custom elements can co-exist with SSR Shadow DOM by ensuring that the SSR content comes before any async script tags. Later, when issue [809](https://github.com/w3c/webcomponents/issues/809) is solved, the implementations can get more creative and detect the completion (or start) of shadow root parsing.

What do you think?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/494#issuecomment-648460694