Add DOMParser option to parse declarative shadow DOM

[mfreed7]

I'm splitting this out from the discussion that starts on this comment https://github.com/whatwg/html/pull/5465#discussion_r1042020381 and then jumps to overall issue comments starting here https://github.com/whatwg/html/pull/5465#issuecomment-1383927052. This was also previously discussed at length starting at this comment https://github.com/whatwg/dom/issues/912#issuecomment-725900521. That issue has much more context on why there needs to be an opt-in for DSD at all.

The current spec PR has DOMParser.parseFromString(html,"text/html", {declarativeShadowRoots: true}) which is the only API that lets you imperatively parse HTML that contains declarative shadow roots.

There is a question about whether we need to add this, and whether instead we should make Sanitizer's setHTML() the only DSD-aware parser API. That requires some changes to the Sanitizer (https://github.com/whatwg/html/issues/8627), in particular giving setHTML() a sanitizer: "unsafe-none" argument that bypasses all sanitization.

[keithamus]

I just want to clarify your concern by attempting to summarise:

• CSP is great for enforcing policy constrains and preventing regressions but...
• CSP is difficult/impractical to partially enforce, and so all callsites must comply before turning on, which means...
• One must rely on static analysis in the interim, which allows for enforcement of first-party code but...
• It leaves the gap open for third party dependencies which can't reasonably participate in static analysis.
• Additionally static analysis may not be robust enough depending on how the API is designed.

[koto]

I think it's the right summary when it comes to the static analysis angle, my concerns about the API shape are however a bit more generic. I find it beneficial if identifying obviously XSSy string->DOM calls from obviously safe ones was possible with little grey area in between - for browsers, humans and all kinds of tools. An additional cognitive load of an extra function name seems better than one introduced by the option bag field.

[mfreed7]

For visibility, I just want to mention that this issue is (in my opinion) closed by https://github.com/whatwg/html/pull/9538. That is a PR that describes two new parsing APIs, Element.setHTMLUnsafe() and Document.parseHTMLUnsafe(), both of which parse declarative shadow DOM content natively. They don't suffer from the compat issues that cause problems for DSD content with innerHTML or DOMParser, and they're a future direction for the platform for parsing and sanitization.