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

@mfreed7 this is very exciting to see coming together!

Two things come to mind in reviewing the explainer that I'd love your thoughts on...

Would you be open to comparing an additional baseline or maybe a parallel set of baselines? In particular, I experience using `shadowRoot`s predominately with custom elements as seen in the [syntax of your proposed solution](https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#syntax). However, without a declarative approach currently these `shadowRoot`s are created by a single element upgrade process. It's very likely that I misunderstand the custom element upgrade process to perform differently that your current array of tests, but it would seem from the outside to amount to fewer bytes over the wire (for the reduction of duplicated `<template>` elements) and likely faster (for being closer to the metal of the browser). Whatever the results, I would see coverage of this comparison as a nice addition to your explanation and further clarity as to the correct path forward in relation to some of the alternatives you've already listed.

What thoughs have you follow up on relative to the complexity ceiling of this approach? For instance the relatively benign `shadowRoot` that you rely on in your example is both low cost of duplicate across multiple instances of an element with a `shadowRoot` and doesn't appear to point to the possibility of more complex elements relying on elements with `shadowRoot`s being a part of their template and/or light DOM. Would you see this approach finding or needing any technical limitations when usage progresses in that direction?

Thanks in advance, looking forward to future possibilities here!

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