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

@plinss, @hober, @atanassov, @dbaron and I discussed this at our breakout this week (will link to minutes once published; that will happen after the plenary meeting tomorrow).

* We agree that reusable templates would be a good upgrade, and that there's no need to block on having a full solution available there, since it could be layered in later.
   * We didn't have a good idea of how to research how often Shadow DOM content would vary between instantiations of custom elements at the point of serialization - perhaps this is something that could be investigated as part of an origin trial or similar?
* We read the additional explanation of [how `innerHTML` works with closed shadow roots](https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#closed-shadow-roots) which you linked to - it does answer Tess' question, and we would suggest integrating that directly with the [Serialization](https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#serialization) section rather than having it as a separate subsection in a totally different section of the explainer (even if it does happen to be immediately afterwards).
* We discussed the idea of combining the arguments to `attachShadow()` into a single content attribute, and agreed that it's probably not a good idea (and premature in any case) to try and design some kind of microsyntax to serialize these into a single attribute. If in future we do end up with many `shadowrootdelegatesfocus`-type attribute, we could investigate what type of simplification might make sense at that point.

We had a longer discussion on the subject of supporting streaming shadow root contents.

It does seem like this would be a preferable default option, if it wasn't for the implementation cost, so it would be good to understand just how significant the implementation cost would be. 

Specifically, not making streaming the default option now means that if it does get added in the future, it will be an additional implementation burden on potential future implementations to support the flag, and on authors to enable it. (We did note, however, that in practice that is unlikely to be very many authors, since this would probably be done by server-side library code.) Adding streaming as a default later on didn't seem feasible, since it would need to be feature-detected.

We also thought it might be worth exploring whether there might be a way to compromise to get at least some of the user experience benefit of streaming without needing to solve all of the complex implementation issues.

* For example, could you defer only script execution until all shadow content has parsed, and then later add an option to execute scripts as they stream?




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