| 08:19 | <foolip> | I don't see an entry in the WHATNOT meeting notes for today, the meeting is happening right? |
| 09:00 | <Noam Rosenthal> | Yes I think so! |
| 10:58 | <Noam Rosenthal> | Deferred scripts inserted with createContextualFragment() are considered "not parser inserted" https://html.spec.whatwg.org/multipage/dynamic-markup-insertion.html#dom-range-createcontextualfragment 8.2 So createContextualFragment basically ignores the defer attribute |
| 11:28 | <zcorpan> | Noam Rosenthal: OK. Maybe that's good enough for setHTMLUnsafe. I wonder though if it would be good to set async=false for inline scripts (both for setHTMLUnsafe and createContextualFragment). cc hsivonen |
| 11:40 | <Noam Rosenthal> | annevk: for creation/insertion difference, I think the sanitizer currently is not set to prevent early image loading, regardless of the inert document in the fragment parsing algorithm. https://wicg.github.io/sanitizer-api/#set-and-filter-html stage 4 adds all the nodes into a fragment in this document, which would trigger image loading before sanitation starts. Not sure if this is an important use case for the sanitizer |
| 11:41 | <Noam Rosenthal> | ... in the same manner that this loads an image: new Range().createContextualFragment('<img src="/bla.png">') |
| 11:57 | <freddy> | Noam Rosenthal: I suppose the setHTML step should say that a temporary inert document is created and that the DocumentFragment is created for that temporary inert document? Can you file a bug? |
| 11:59 | <freddy> | We totally should prevent image loading and our implementation in Firefox appears to do the right thing |
| 12:01 | <Noam Rosenthal> | Sure, done. https://github.com/WICG/sanitizer-api/issues/363 |
| 14:14 | <annevk> | Noam Rosenthal: I guess we might have to refactor the HTML parser in some way so you can parse into a DocumentFragment. I doubt anyone is up for changing their createContextualFragment() implementation at this point. |
| 14:37 | <Noam Rosenthal> | sounds right. I can't think off the top of my head of other elements that have creation-time side effects, but if there are we should probably have tests for them in the sanitizer |
| 14:38 | <Noam Rosenthal> | ... maybe custom element constructors |
| 14:39 | <Noam Rosenthal> | but that's a script thing |
| 14:51 | <annevk> | Media elements do something similar. |
| 16:52 | <annevk> | sideshowbarker: I'm hitting the validator banning role=directory. It seems that Bikeshed generates it on <ol> elements. See https://github.com/whatwg/dom/pull/1430 cc TabAtkins |
| 16:52 | <TabAtkins> | sideshowbarker: I'm hitting the validator banning role=directory. It seems that Bikeshed generates it on |
| 16:53 | <TabAtkins> | Lemme do a quick fix and release |
| 16:54 | <TabAtkins> | (I assume my use of this role came from existing W3C specs) |
| 16:56 | <annevk> | Thanks! sideshowbarker: might be a good idea for the validator CI to also validate some WHATWG standards so these fixes can be coordinated a bit better. |
| 16:57 | <TabAtkins> | A jillion W3C specs have this makeup currently too, so I presume the CI isn't running over existing specs |
| 17:06 | <TabAtkins> | All right, new Bikeshed version published minus the role |
| 18:39 | <bakkot> | does anyone know offhand if a request's destination is supposed to participate as a component of the key in the HTTP cache? (Actually what I care about is the type: "json" attribute on module requests, but as I understand it the way that gets reflected in the fetch machinery is as a destination.) |
| 18:39 | <bakkot> | I'm seeing different behaviors across browsers - in Chrome and Safari, doing import data1 from './data.js'; import data2 from './data.js' with { type: "json" } only triggers a single network request, whereas in FF it triggers two |
| 18:41 | <bakkot> | this becomes more relevant with type: "text" because then you can reasonably request the same resource in multiple ways. a server might not want to make a script available for importing with type: "text", but it can only do that if it actually gets to see the second network request |
| 18:42 | <bakkot> | the Sec-Fetch-Dest header seems a lot less useful if destination isn't a part of the cache key |
| 18:49 | <nicolo-ribaudo> | I remember writing a wpt test asserting two separate requests for a JSON and CSS import |
| 19:14 | <bakkot> | I found https://github.com/web-platform-tests/wpt/pull/41665 but it doesn't look like it contains such a test, at a quick glance |
| 19:21 | <bakkot> | (specifically, import-declaration-type-json.js and import-declaration-type-css.js pass different query parameters, and everything else just uses different URLs afaict) |
| 19:38 | <bakkot> | ok actually it's not even showing up in the network tab so I think it must be ending up in the module cache, which is I'm almost certain is wrong |
| 20:04 | <nicolo-ribaudo> | Mh I remember having to touch some python code to serve the two responses, maybe I ended up never submitting the test though. I'll check tomorrow |
| 22:05 | <Noam Rosenthal> | bakkot: isn't the common practice for this having Vary: Sec-Fetch-Dest in the response? |
| 22:59 | <bakkot> | yes, that would make sense. I was trying that as well but it was doing anything, and I thought maybe that header wasn't allowed in Vary but I'm now pretty sure the caching is happening in the module machinery in Chrome/Safari, not the HTTP cache, and so Vary isn't relevant at all. |