Re: [whatwg/dom] [Declarative Shadow DOM] How should we build the "opt-in" for fragment parsing of declarative Shadow DOM? (#912)

@domenic thanks for the feedback!

> Should be `allowDeclarativeShadowDOM` per https://w3ctag.github.io/design-principles/#casing-rules

Somehow I always get that wrong, even when I try to get it right. Thanks - will change.

> > allow-declarative-shadow-dom sandbox flag
> 
> In general I don't think we're adding new sandboxing flags; instead [document policy](https://w3c.github.io/webappsec-permissions-policy/document-policy.html) seems to be the right replacement? That also gives you the right header-based opt-in for the main document, I believe. @clelland would know more.

Ok, I wasn't sure what the situation was there. It doesn't [seem](https://caniuse.com/?search=document%20policy) like Document Policy is quite available everywhere (anywhere?). That's why I went with the [more supported](https://caniuse.com/?search=sandbox) sandbox attribute, which does seem to have a natural linkage over to Document Policy when available, no? This issue just needs an imperative way to enable/disable declarative Shadow DOM for use by sanitizers, and doesn't need a header-based opt-in. (That's #913, still up for debate.) I'll read up on Document Policy more, but is there a way to implement this that would be supported today, without requiring other implementers to also implement Document Policy? I suppose they could just **not** support DSD for `<iframe>`s **ever**, but it seems like that would break some use cases. Maybe not.

> Also when at all possible it'd be better to avoid global toggles in favor of method parameters. So e.g. instead of `document.allowDeclarativeShadowDOM = true` you'd do `div.setInnerHTML(html, { allowDeclarativeShadowDOM: true })`.

Ok, I avoided this because I didn't want to invent a new API (`setInnerHTML()`) just for this. But if that's the preferred way of doing things, I can make that change. I think it's important to point out that (at least from the implementation) it seems like we'll need a flag on `Document` anyway. Other APIs, like DOMParser and XMLHttpRequest, just create a document and then call the existing parser algorithm, so setting a flag on those new `Document`s before calling the algorithm seems natural. So the only question is whether to expose that flag directly (as I've done) or hide the flag and only expose it indirectly through other APIs. Can you help me understand why that's better?


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/912#issuecomment-722732773