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

@alice and @hober, thanks for the feedback! See below for some responses.

> I'm surprised and concerned that this enables the serialization of closed shadow trees by code outside the shadow tree. Doesn't that defeat [the purpose](https://annevankesteren.nl/2019/10/encapsulation-theory) of having closed shadow trees in the first place? I suppose you might want such a feature for a browser's "save this page" feature, or maybe for server-side code, but perhaps that would be better served by an API that's not available to page authors.

I would be concerned about this also... but I don't agree that the proposal allows this. Note that [serialization of closed shadow roots](https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#closed-shadow-roots) is only allowed if the closed roots themselves are explicitly passed in. So unless the code already has access, the closed shadow root is not serialized. Does this clarify the situation, or did I misunderstand your concern here?


> `delegatesFocus` probably won't be the last option that gets added to [ShadowRootInit](https://dom.spec.whatwg.org/#dictdef-shadowrootinit), and I think this proposal implies that we'd need to add a `shadowrootfoo=""` attribute to `<template>` for every boolean `foo` we add to ShadowRootInit in the future. That seems kinda messy.
> 
> Instead, could we maybe have a single `shadowrootoptions` content attribute containing a DOMTokenList representing these boolean flags (e.g. `shadowrootoptions="delegates-focus future-thing-1 future-thing-2"`)?

I completely agree that this is "ugly". I did think about a DOMTokenList-like solution here, but the problem is non-boolean parameters. For example, the next such attribute I can see coming is the 'slotAssignment' parameter in the [Imperative Shadow DOM Distribution API](https://github.com/yuzhe-han/webcomponents/blob/gh-pages/proposals/Imperative-Shadow-DOM-Distribution-API.md), which isn't exactly binary. In that case, it likely could be made binary, but there are no guarantees about future parameters. In a world where some parameters take values, would you still prefer having some be part of a DOMTokenList and others be standalone attributes? Are there other precendents in the Web Platform that we can draw inspiration from? I'm really open to suggestions here.


> Regarding the [timing of attachment](https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#timing-attach-the-shadow-on-opening-or-closing-template-tag), we noted that the primary reason for attaching the shadow root when the closing `<template>` tag was parsed was due to implementation complexity.
> 
> This is explicitly counter to the reasoning in the [priority of constituencies](https://w3ctag.github.io/design-principles/#priority-of-constituencies).
> 
> I understand that a non-zero number of pages are of the form
> 
> ```
> <my-app>
>   #shadowroot
>     <rest>
>        <of>
>           <the>
>              <app>
> </my-app>
> ```
> 
> For these pages, it seems like the entire page would need to be parsed before any content would show up. Is that right?
> 
> Is there any chance of revisiting this decision?

You are correct that the rendering will happen only at the closing tag of the outer-most `<template shadowroot>` tag, which precludes "streaming". And this is unfortunate.

Nominally, I agree that changing this API to be less powerful, and correspondingly less complex, runs counter to the priority of constituencies. However, there is a pragmatic interpretation of the priority of constituencies here: if the implementers are unwilling to embark on adding this feature because they believe the effort required is not justified, then users and authors interests haven't really been prioritized, since they don't get the new feature at all. In other words, that would be making the perfect the enemy of the good. In this case, I believe there is standalone value to the non-streaming version of declarative Shadow DOM, and if the demand for the "streaming version" proves to be worth the effort, then that can always be added as a follow-on feature. For example: `<template shadowroot=open streaming>`. Would you agree?


> With the proposal to [use an idref to an existing template](https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#instead-of-inline-contents-use-an-idref-to-an-existing-template), it seems like this would address some of the concerns we had about this feature pointing to a missing "declarative custom element" feature.
> 
> @justinfagnani has pointed out to me that reusable elements _are_ a form of compression, although it's true that compression is also a form of compression!

I do agree that this, also, is a good upgrade for this feature. However, as you know, there are still real problems with a general id-ref based solution of any kind, and those would need to be solved first. Again here, I think there is a natural expansion path for "shared" declarative shadow DOM with something like `<template shadowroot=open shadowtemplate=#magic-global-id>`.

One point I want to make here - I really believe this should be declarative **Shadow DOM** and not tied to custom elements. I'm not sure if that's what you were suggesting, but I think we have separate features (Shadow DOM and Custom Elements) and we should try to avoid requiring one to use the other.


> Regarding the technical issues:
> 
> * It seems that reasonable answers could be found to the question of what happens if `<template>` is defined after the `<custom-element>` (particularly since this would be poor practice, like having two `<template shadowroot>`s inside a single host element.

Agreed.

> * Regarding IDREFs piercing shadow boundaries, this seems like a question that badly needs a solution. We have been working on this for AOM, with one strawman proposal being to [introduce a `globalid` attribute](https://github.com/whatwg/html/issues/5401#issuecomment-629982041) which can be used for shadow-piercing references (but not used in a `getElementById()` lookup). This would also address your comment about AOM IDL attributes in the "Other unanswered questions" setction.

I have been following this discussion, and I do like the direction it is heading. But as you know, there are still unanswered questions, and I'd like to avoid holding up this proposal on a full resolution of the idref problem. Pragmatically, how close to agreement do you think the 'globalid' attribute is?

> * The question about "how often this would be helpful" seems like one that is worth answering in earnest - how often is shadow DOM contents strictly boilerplate, with stateful content slotted in, vs encapsulating state as well as structure?

This is a good question, for which I don't have a great answer. I'm not sure what the best way to go about trying to find out - suggestions?

> One meta-comment: we love how thorough and yet succinct and readable this explainer is!
> 
> Just one suggestion: please consider adding a table of contents using [doctoc](https://github.com/thlorenz/doctoc) as recommended in our [Explainer Explainer](https://w3ctag.github.io/explainers#table-of-contents-if-the-explainer-is-longer-than-one-printed-page).

Glad you liked it! Yes, I can definitely add a TOC - will do.

Thanks,
Mason

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