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

So I've modified the Chromium implementation to disable declarative Shadow DOM, unless opted-in, for all six of the parser entry points listed in the OP here. I also added [WPT tests](https://github.com/web-platform-tests/wpt/pull/26398) for each of these.

In essence, the API is mostly just an `allowDeclarativeShadowDom` property added to most of the relevant APIs. For iframes, I've added a new `allow-declarative-shadow-dom` sandbox flag. In all cases, it seems relatively simple to use from a developer point of view, and it should completely mitigate the problem use case here for old client-side XSS sanitizers. Here's an example usage, for the `innerHTML` case:

```javascript
  const div = document.createElement('div');
  const html = '<div><template shadowroot=open></template></div>';
  div.innerHTML = html;  // No Shadow DOM here!
  document.allowDeclarativeShadowDom = true;
  div.innerHTML = html;  // Declarative Shadow DOM enabled!
```

The implementation seems pretty clean, and I'm guessing (hoping?) that the spec changes should be similarly straightforward. Mostly, this is a new flag on the `Document`, which is set from the various parser entry points (e.g. `DOMParser`, `XMLHttpRequest`, etc.). And a check of this flag from the parser, for `<template>` start tags. My plan is to start modifying the declarative Shadow DOM spec PRs to incorporate this change. But if someone sees a problem with the above, now would be a great time to tell me!



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