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

@domenic you made the case against the `Document` state approach, which I did agree with. But in light of the seemingly more serious security concerns around adding a new unsafe sink above, perhaps this is the lesser of the evils?

```javascript
document.allowDeclarativeShadowDOM = true;
element.innerHTML = contentIncludingDSD;
```

It does add state to `Document`. But it fixes the sanitizer bypass, it avoids adding a new XSS sink, and it's easy to use.

Again, I think it is important to remember that the **entire motivation** for this "opt-in" mechanism is to avoid the risk that **existing sanitizer libraries** don't know how to deal with DSD. After that, I'd prefer a world where DSD is just part of HTML, so it's natural to "allow" declarative shadow content anywhere you'd normally parse "normal" HTML. @domenic for example you said the global state was bad because you could create a `Document`, set the flag, and pass it to a framework that doesn't know how to deal with DSD content. But unless that framework is a sanitizer, that should be ok. That's the same thing as when other new HTML elements are added to the platform, and existing frameworks don't natively "understand" them.  If the framework in your example **is** a sanitizer, it shouldn't be getting its parser document from outside, or it's already broken. Would you agree?

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