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
(end)
<bkardell> masonfreed: I'm not sure I get the data in the slide that says ~4%