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).

Thanks for the feedback! Responses below.


> * 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.

Great news, thanks.


>   * 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?

Yes, I was curious about this as well, since I only heard it anecdotally while developing this feature. I will make it a point of any origin trials to try to gather more data here.


> * 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).

Good suggestion! Done. It looks similar, but I've moved the two sections ("Closed shadow roots" and "Additional arguments for attachShadow") out of the "Other Considerations" section up into the "Serialization" section proper.


> * 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.

Sounds good, thanks.


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

I agree here - streaming would be preferrable. The problem is (I think) that the implementation cost is seen (e.g. [here](https://github.com/whatwg/dom/issues/510#issuecomment-372224104)) as being due to security risks and bugs. I think the difference in "pure" implementation cost is actually quite similar for the opening vs. closing tag. It is just that having a live shadow root document into which elements are parsed is new, and opens the usual Web can of worms of possibilities for what can happen. I do empathize with that concern. This proposal (non-streaming) gets the syntax, the use case, and some data up and running, and from there we can hopefully expand to a streaming version later.


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

I agree that if we add a streaming option (e.g. `<template shadowroot=open streaming>`) later, this will require some change to the content, e.g. to add the "streaming" attribute. As you point out, that is likely to be easy to change, due to the use of server-side library code. On the implementation side, I don't actually think it will be much of an implementation burden. The code to implement the existing (non-streaming) version of this feature is relatively small, and much of it could likely be shared by both versions. But that, of course, remains to be seen. From your comment, it sounds like you're reluctantly ok with this choice - please correct me if I'm wrong.


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

I would love to do this, but as I mentioned above, I think the devil (and implementation cost) is in the details. As far as I understand it (and I'm open to pointers here!), we can either create the shadow root upon the opening or closing tag. Full stop. The current proposal uses the closing tag, because it can then re-use the (debugged, working) machinery for `<template>` as-is without modification. If we move to the opening tag, the can of worms is now open, and any/all security bugs are possible. I agree that deferring scripts might alleviate some of the risks, but even implementing that script deferal needs to be done carefully, and thoroughly. For example, what happens if script moves an existing `<script>` node into the currently-being-parsed `#shadowroot` - should it execute?

Let me know if you have suggestions here - I'd love to get a streaming version implemented that will get multi-implementer support. As-is, I still have **no indications of support** from the other engines, and that is without adding more complexity.

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