Re: [whatwg/dom] Declarative Shadow DOM (#831)

> The best way forward is to come up with a solution that satisfies all the constraints. It's possible that the problem is over constrained and we need to pick the least problematic / evil solution among them but we're not there yet.

Agreed, on all counts. We need to try to satisfy all of the constraints, and if the problem is over-constrained (as this one is, like most interesting problems), choose the least problematic way forward. Which is great, because I believe [that's where we currently are](https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md), as a result of all of the discussion that's been happening on this thread.

> > As for `<shadowroot>`, when Declarative Shadow DOM was under discussion in 2017, @rniwa was just one among many voices, including Chrome devs, saying that adopting a new element like `<shadowroot>` was a non-starter. The explainer for Declarative Shadow DOM has a whole section on this ("[Syntax: `<template shadowroot=open>` vs. `<shadowroot>`](https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#syntax-template-shadowrootopen-vs-shadowroot)") and it quotes @rniwa's [comment from 2018](https://github.com/whatwg/dom/issues/510#issuecomment-372224104) as evidence that implementers won't support adding `<shadowroot>`, due to the potential for security bugs.
> 
> That comment specifically refers to the old proposal of introducing a new HTML parser macro which interprets `<shadowroot>` as a start of shadow root, then stream its content into the shadow root, and not creating an element for `<shadowroot>` itself. That has a number of drawbacks and implementation challenge as I pointed out in that comment. Implementing the proposed semantics of `<template shadowroot>` using a element of new name doesn't pose nearly the same issues as far as I've thought about it thus far.

@dfabulich, thanks for pointing out [that section of the explainer](https://github.com/mfreed7/declarative-shadow-dom/blob/master/README.md#syntax-template-shadowrootopen-vs-shadowroot) - we've already had that discussion (both at the [March F2F meeting](https://www.w3.org/2020/03/23-components-minutes.html), and several times within the [issue thread](https://github.com/whatwg/dom/issues/831)) and arrived where we are, at `<template shadowroot>`. As discussed, the key downside of a `<shadowroot>` element, independent of parser macro vs. new element, is that there will be **severe backwards-compat** issues for browsers that do not implement this feature at the same time. Styles will leak out, and scripts will be broken. This is precisely why `<template>` was chosen here - it already offers this backwards compatibility, since its contents are inert. Changing to `<shadowroot>` is surely a worse solution than the current `<template shadowroow>` approach.

> 
> > You say you haven't given up hope on this feature, but if `<shadowroot>` is the only way forward, and `<shadowroot>` is a non-starter, then I see no way forward at all.
> 
> You're making a whole bunch of assumptions there. I don't necessarily think `<shadowroot>` is the only way forward even though that might be a promising approach and there are many ways to define what `<shadowroot>` would do, not all such definitions are problematic. We just need to find a solution that satisfies all the constraints we've identified thus far.

I still don't understand how this solves the XSS issue. For users that override the defaults of sanitizers (or just use "bad" sanitizers), new elements like `<shadowroot>` could still be ignored. And as I mentioned, for sanitizers that use the built-in parser for all HTML parsing, **any** declarative shadow DOM solution poses this risk. No matter what the tag name is, `<template shadowroot>`, `<shadowroot>`, or `<my-super-secret-declarative-tag>`. These sanitizers will send the raw HTML into the browser's parser, and if declarative shadow dom is a thing, the parser will return DOM containing shadow roots. Please help me understand how this fixes the XSS problem, at all.

> Even if all major sanitizer libraries did eventually support this, it's still problematic that there are existing sanitizers that may end up with XSS. We may need to pursue some kind of opt-in mechanism for this so that the existing content that's not actively maintained doesn't get a new XSS vulnerability.

Surely we can't take the position that **any** bad/old/misconfigured sanitizer available on the internet should keep us from adding new capabilities to the web. If that were our position, I could stop all further progress on the Web Platform by simply releasing my own Cool Fast Sanitizer (TM), which I'll post here for convenience:

```javascript
function MasonsCoolFastSanitizer(dirty_html) {
  const clean_html = dirty_html; // As fast as pointer assignment!
  return clean_html;
}
```

> I emphasize with people getting frustrated here. This must be such an easy feature for browsers to add, you might think. In reality, there is a lot of nuances and issues we have to consider and take care of. So please don't be discouraged and think that this isn't going anywhere. If I thought this isn't going anywhere or a totally bad idea, I wouldn't be actively engaging in the discussion like this over weekends :)

@rniwa, I'm really glad to hear that you're nominally supportive of adding this feature. **That is very encouraging!** Let's get this feature across the finish line - there are clearly developers who would like to use Shadow DOM but cannot because there is no declarative solution.



-- 
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/831#issuecomment-716223443