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

Ok I almost have another patch landed in Chromium that makes the changes you've recommended here:

 - Remove `allowDeclarativeShadowDom` state from `Document`, `DocumentFragment`, etc.
 - Replace the above with call-site parameters for all but `DOMParser`, which gets a constructor parameter.
 - `innerHTML` no longer supports Declarative Shadow DOM, ever.
 - A new `setInnerHTML()` function allows opt-in access to DSD through a second options-bag argument.
 - Several of the less-well-lit parser APIs do not have an opt-in for declarative Shadow DOM. For example `XMLHttpRequest`, `createContextualFragment`, and `document.write()` will not support DSD. (`document.write()` in a synchronous script as part of the main document will still be supported.)
 - The sandbox flag has been removed from `<iframe>`s completely. My new plan is to use Document Policy to allow more fine-grained control over declarative Shadow DOM for `<iframe>`s. For now, `<iframe>`s always support declarative Shadow DOM. I will work on the Document Policy change in a subsequent CL, once I get the rest of this squared away.
 - `allowDeclarativeShadowDOM` has become `allowShadowRoot` for all of the options above.

You can see how these look by reviewing the [WPT test changes](https://github.com/web-platform-tests/wpt/pull/26482) that were required.

As always, comments appreciated.

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