Declarative Shadow DOM

28 October 2020


bkardell, dandclark, gregwhitworth, hober, hsivonen, jamesn, Jemma, leobalter, melanierichards, miriam, plh, Rob, smaug

Meeting minutes

<masonfreed> Hmm, how do I get Zakim to log the minutes back to an issue?

<plh> hi mason

<plh> it requires a different setup since it's a specific bot

<plh> unfortunately, I can't do that at this time

<plh> (hosting a separate session right now before yours)

<masonfreed> Oh ok. Is there any way to get that to happen after the fact? I.e. will there be a log kept somewhere that I could manually link from the issue?

<plh> yes, the log will be on w3.org in any case

<plh> I'll do the proper setup for that

<plh> I'll join and setup the zoom a few minutes before the top of the hour

<plh> and manage the queue for you

<plh> will you have slides?

<plh> or materials to present?

<plh> or will it just be a discussion around issues?

<masonfreed> Great! Thanks. Yes, I'll have some slides, likely on screen for most of the meeting, to guide the discussion. Would you, by chance, be able to present those? I've got only a laptop screen with limited real estate.

<plh> I won't be able to present since I'll monitor the queue/zoom

<MikeSmith> plh: masonfreed: about the minutes from yesterday, I see we failed to invoke the command to generate the formatted minutes

<masonfreed> Ahh ok, I can present.

<plh> MikeSmith, oops. my mistake. I'll fix that

<masonfreed> And re: yesterday's minutes, that's too bad.

<plh> I'll get them online

<MikeSmith> masonfreed: yeah can be fixed

<MikeSmith> just needs to be done through an extra manual step

<masonfreed> Great!

<plh> thank you for letting me know Mike

<MikeSmith> hai

<masonfreed> https://‌docs.google.com/‌presentation/‌d/‌1CR4TivoLxvpWreOy88iBVyrCGY68VYTrGttDgCaGBO4/‌edit#slide=id.p

<plh> zalkim, start meeting

<hsivonen> I don't see anyone else on Zoom. Have I done the time zone math wrong?

<bkardell> I see zzom just fine hsivonen

<bkardell> hsivonen: maybe you clicked the wrong one? that happened to me earlier today

<MikeSmith> hsivonen: https://‌us02web.zoom.us/‌j/‌81640202506?pwd=WFN2NlhkV1c1SVpqd2l1RG5oVkIyUT09 is the Zoom link

<annevk> (ElementInternals.prototype.shadowRoot also works for non-declarative shadow roots, aiui.)

<plh> Slides: https://‌docs.google.com/‌presentation/‌d/‌1CR4TivoLxvpWreOy88iBVyrCGY68VYTrGttDgCaGBO4/‌edit#slide=id.p

rob: has there been any further thinking on styles?

mason: best practice is to include a style tag inside the declarative shadow root

mason: adoptedStyleSheets has a few limitations: no way to serialize them in HTML

mason: there are browser optimizations that make embedding <style> acceptable

<gregwhitworth> +1 to what masonfreed said, I don't want to block declarative on styles

justin: I'd also like to support adoptedStyleSheets here

justin: perhaps a <template> could reference a stylesheet ID that would be attached as an adoptedStyleSheet

<gregwhitworth> masonfreed: I presume there's an issue open for determining style?

fantasai: I need to put the entire contents of the shadow root into the template if I'm doing this declaratively?

<fantasai> fantasai: So if I have like 150 cards in a catalog and each has a shadow dom template, I have to include the entire template code inline for each card element?

mason: yes

mason: to solve that, we'd need some way of referencing a shaded shadow root

mason: there are also cases where the shadow trees will differ

fantasai: seems impractical

fantasai: like we're not solving the real problem here

<dandclark> I'm in agreement with others so far that we should work out solutions for declaratively putting sheets in adoptedStyleSheets, and add an option to serialize them back out with getInnerHTML. But that shouldn't need to block the current proposal.

fantasai: for this to be practical, seems like we need a way to reference templates in the same document

justin: here we're using the template tag simply to serialize a shadow tree

justin: this is effectively what SSR is already doing with everything today

justin: we could solve the problem of sharing templates, but that's in the future

tab: if you have a catalog with lots of shared elements, you would just have a lot of DOM

tab: that wouldn't be weird

fantasai: But I wouldn't duplicate all the style and script elements

tab: The style elements can be optimized so that in practice it's not a bad thing

tab: Adding in the shadow DOM part doesn't change thing — this is a strict improvement over what we have today

tab: it's possible that you could be sending script or style multiple times, but that's what caching is for

tab: in practice you don't pay a penalty

tab: We can address the ability to share shadow trees across elements, that's a separable problem

tab: We shouldn't try to conflate those two features early now

fantasai: So you're creating a serialization format, not really creating something that's intended for authoring use?

tab: Yes

mason: This is just as hand-authorable as all of HTML today

fantasai: Again, I don't repeat my styles when I hand-author pages

<bkardell> but it is a necessary step toward not doing that, I think

mason: Agree

mason: I don't think that should become a blocking issue for this

<gregwhitworth> +1 to having an issue

<bkardell> +1

(mason resumes presentation)

<annevk> (It seems weird for the innerHTML setter to disregard shadow roots but the new getter to serialize them nonetheless...)

hsivonen: when the sanitizer uses its own parser, why is preservation of the shadowroot attribute a sign it is broken?

<annevk> not a sign, I think

mason: Let's discuss that after I get to these slides

mason: Are there other things I haven't mentioned?

(mason resumes presentation)

<annevk> (I guess the other parsers entrypoints we have are XMLHttpRequest, srcdoc="", document.open/write() on an <iframe>. Apart from the first one none of them are prolly good entrypoints for a sanitizer though and the first one isn't good either...)

<hsivonen> (createContextualFragment)

<annevk> (Although maybe it is for parsing documents rather than fragments... And with a data URL you don't have to hit the network.)

anne: (explains his comments above)

anne: createContextualFragment might be good for sanitizing

mike: if there are any web developers here today, it'd be nice to hear from them on the different options Mason presented

mason: +1

justin: on that point, I think the vast majority of the use cases are on the main document

justin: I'm okay with declarative shadow DOM being opt-in

justin: as long as it doesn't require a header

justin: There are some other intentions for template: like declarative custom elements

justin: A sanitizer might not expect them

whatever solution applies here should also be able to be used in those other scenarios

<Rob> Agreement from me on the points Justin just made.

<TabAtkins> http header would make me sad :(

<justin> same

<Lars> I agree

mason: How do people feel about a HTTP header?

<miriam> +1

brian: Too high a bar

<EliHowey_> +1

westbrook: +1

mike: Do we have any precedents where we've been successful with an HTTP header?

<graynorton> Just to clarify: Justin said he was okay with declarative Shadow DOM being opt in for cases *other than* the initial parse on page load

greg: Is there any reason why we can't use hinting capabilities, like a meta tag or something like that nature?

greg: opt in at the doc level?

mason: No, you need to have it out of band

mason: if you were writing an XSS exploit, you would just include the meta tag

hsivonen: If there are people who want to use a meta tag, and a meta tag is flaky, then implementers forget about it

<justin> For opting in on APIs: setInnerHTML() has a nice symmetry to getInnerHTML()

hsivonen: One concern I have about opt in
… we have full document parsing and fragment parsing
… and people discover these are different, they're sad
… but I don't see how we could do this without an opt-in

<koto> +1

hsivonen: if we do this feature at all, and add another dimension (opt-in) people will be sad

mason: People seem to agree that we need an opt-in for scenario #1

<annevk> (Can someone share a link to the slides? I have a hard time remembering the scenarios.)

mason: ... are there ways to find if scenario #2 is just a hypothetical

hsivonen: What gives server-side sanitizer the right to preserve the shadowroot attribute?
… if the contents of the template are assumed to be inert,
… why wouldn't the sanitizer maintain an allowlist of what is safe
… If it didn't, it would be broken to begin with

mason: There are different ways of broken
… If something was safe before, but not safe after declarative shadow DOM, that's a problem

mason: For scenario #2 the sanitizer is already unsafe today if it's sending template elements

hsivonen: I disagree

<bkardell> "4% of your users" seems like the wrong way to phrase that masonfreed

hsivonen: Maybe today IE 11 is still getting security properties today
… I don't buy the notion that, because those are broken, this would be okay
… It's more interesting to understand if it's today allowing shadowroot attribute, what else is it allowing? Why is that not an XSS?

mason: It's not insecure today, you can pass through a template with a shadowroot attribute, and that's safe today

koto: In the past we have introduced new ways to include scripts

koto: That said, I find the setup of a sanitizer

<hsivonen> (regrets about having to drop off at the top of the hour)

koto: that passes through template elements with unknown attribute names
… I don't see the use case for that

koto: ... It sounds like a quirky (?) sanitizer to support in your application

<eeeps> Just want to say that document policy might be a better fit for an HTTP header, if that's necessary, than CSP https://‌github.com/‌w3c/‌webappsec-permissions-policy/‌blob/‌master/‌document-policy-explainer.md

mason: I think we've reached a rough consensus that we should address scenario #1 with opt-in
… No consensus on scenario #2: how bad it is, how to address

leobalter: Appreciate the homework that mason has done here

<plh> zaki,, close the queue

leobalter: should we have a TAG review followup on this XSS topic?

mason: Excellent suggestion, brought it up, haven't heard back


<bkardell> masonfreed: I'm not sure I get the data in the slide that says ~4%

Minutes manually created (not a transcript), formatted by scribe.perl version 123 (Tue Sep 1 21:19:13 2020 UTC).


Succeeded: i/mason: yes/fantasai: So if I have like 150 cards in a catalog and each has a shadow dom template, I have to include the entire template code inline for each card element?/

Succeeded: s/style/style and script/

Succeeded: s/not really/creating a serialization format, not really/

No scribenick or scribe found. Guessed: jan

Maybe present: anne, brian, fantasai, greg, justin, koto, mason, mike, tab, westbrook