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

My general observations and takeaways from the TPAC [meeting](https://github.com/whatwg/dom/issues/831#issuecomment-718129808):
 1. Styles continue to be a question. While the `<style>` and `<link>` solutions work, people would prefer a solution to "declarative" `adoptedStyleSheets`. There seems to be agreement that this can be pursued separately from the declarative Shadow DOM API. I've opened #910 for this question. It **does not** sound like declarative adoptedStyleSheets should block declarative Shadow DOM.
 2. No other issues were [brought up](https://docs.google.com/presentation/d/1CR4TivoLxvpWreOy88iBVyrCGY68VYTrGttDgCaGBO4/edit#slide=id.ga46b0a94fb_0_6), other than the XSS issue, that people considered to be "blocking" for declarative Shadow DOM. **This sounds like good news** - we just need to solve XSS (ha!) and this feature should be ready.
 3. As described in the presentation, **"Problem <span>#</span>1"** (client side sanitizer using the browser's parser, see [slide 9](https://docs.google.com/presentation/d/1CR4TivoLxvpWreOy88iBVyrCGY68VYTrGttDgCaGBO4/edit#slide=id.ga5141bda34_0_59)), seems to be a problem that people feel **needs a solution**. Further, people seemed to think that changing the various browser parser entry points to **not** parse DSD by default, but require an explicit opt-in, would be appropriate, and not too-great a developer burden. People also commented that there were several other parser entry points that need to be considered. **I'll take an action item to propose some spec changes along these lines.**
 4. Thoughts on **"Problem <span>#</span>2"** (either-side sanitizer using custom parser, and rules that allow `<template anyattribute>` through with all children & attributes unsanitized, see [slide 10](https://docs.google.com/presentation/d/1CR4TivoLxvpWreOy88iBVyrCGY68VYTrGttDgCaGBO4/edit#slide=id.ga5141bda34_0_98)) were **mixed**. The argument that allowing `<template>` through to browsers that don't support it, even though that is ~3.6% of traffic, isn't a strong enough case that this isn't a problem. Developers might assume users on very old browsers are already security-compromised, and therefore configure sanitizers to behave this way despite them. On the other hand, there was fairly overwhelming consensus against adding an HTTP header to opt-in to this feature. And the point was made that sanitizers that allow-list **any** `<template>` attribute are also fundamentally broken. The action plan here isn't clear to me. Here are the options, as I see them:
    1. Don't implement any mitigation for "Problem <span>#</span>2", and assume it isn't a real/prevalent situation.
    2. Add an HTTP header, despite the pushback. This would be XSS-safe, but would likely render this feature ergonomically useless.
    3. Change the name of the "shadowroot" attribute to something starting with "on", since the general assumption is that sanitizers will remove anything starting with "on". So, `<template onshadowroot=open>`. This would be "ugly", but ergonomically fairly low-impact. I don't know how this impacts the other template-related new feature requests, such as declarative custom elements, and template instantiation.
    4. Implement some other mitigation, yet to be proposed. **(Insert your name/idea here!)**

Again, these are my notes. Please chime in if I missed something important. And once again, thanks for the great discussion of this feature.

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