| 09:06 | <annevk> | JakeA: I realized that one thing to remember when beating Apple over the Storage Access API is that the HTTP Clear-Site-Data header is still not properly defined either |
| 09:06 | <annevk> | JakeA: defining Clear-Site-Data properly might actually give us some of the primitives we need to layer a Storage Access API on top that doesn't just do cookies |
| 09:11 | <JakeA> | annevk: Fair, but I'm not criticising Apple for not implementing Clear-Site-Data |
| 09:12 | <JakeA> | The narrative that bugs me is: Chrome is bad for not implementing our API / Ok then how does it work? / Dunno. |
| 09:14 | <annevk> | So afaict it only affects cookies and it probably relies on something that's not specified in HTML, namely a document's cookie URL concept |
| 09:14 | <annevk> | Cookies in general could really use some love |
| 09:15 | <annevk> | But also, that narrative is something Firefox often gets as well and we end up fixing a lot of the mess Chromies left behind... |
| 09:17 | <annevk> | Not really sure anyone is without blame here, but as long as we have similarish goals we should be able to figure something out |
| 09:24 | <JakeA> | There are loads of specs Chrome folks could be doing a better job on, absolutely |
| 09:25 | <JakeA> | I'm definitely not saying Chrome is blameless here |
| 14:21 | <annevk> | Domenic: windows agent |
| 14:23 | <Domenic> | heh |
| 14:49 | <annevk> | wow bugs in getElementById, that's pretty good |
| 15:50 | <Domenic> | DocumentFragment though, that's slightly more recent |
| 15:52 | <annevk> | Fair, added in Oct 2013 |
| 18:42 | <shu> | annevk: Domenic: something came up during the blink side of implementing top-level await around document.write. i want to check my understanding of what ignore-destructive-writes counter is for, and then possibly propose something |
| 18:43 | <shu> | AIUI, that counter is intended so that only inline sync script tags has the legacy behavior of document.write() blowing away everything if there's no explicit document.open() |
| 18:46 | <shu> | now, with TLA, dan's current PR says so long as a promise resulting from a TLA is not settled, that counter is incremented |
| 18:46 | <shu> | it turns out this is not great to implement and has a runtime cost to distinguish those promises |
| 18:47 | <shu> | the current thinking is can we increment that counter to >0 the first time *any* module script tag is executed |
| 18:48 | <shu> | this is backwards breaking, but only for pages that mixes classic and module scripts, and uses destructive document.write, which i reckon is vanishingly small |
| 19:58 | <annevk> | shu: sounds reasonable, not sure why we made it work there to begin with |
| 20:00 | <annevk> | Bit surprising as I thought module scripts were delayed anyway |
| 20:07 | <Domenic> | shu: that sounds great, less document.write() in the wild is always a win. |
| 20:10 | <shu> | cool, though i'm still kinda confused about why, today, tasks queued from external classic scripts and modules are allowed to do destructive document.write()s |
| 20:10 | <Domenic> | tasks queued from external classic scripts doing destructive writes sounds like something the old web would rely on |
| 20:11 | <Domenic> | `setInterval(() => document.write(i++), 1000)` "look, babies Netscape 3 counter" |
| 20:11 | <shu> | right, that's believable |
| 20:11 | <Domenic> | Modules we were probably just trying to make modules more symmetrical with classic scripts |
| 20:12 | <Domenic> | I.e. treat them the same as external classic scripts |
| 20:12 | <shu> | and the separation of throw-on-dynamic-markup-insertion and ignore-destructive-writes is specifically that `document.open(); document.write(...); document.close();` is less bad? |
| 20:13 | <Domenic> | Not really. I think that was an instance that was more "disallow everything we dislike", so we were more aggressive: throwing instead of ignoring, for example |
| 20:13 | <Domenic> | We still weren't aggressive enough to just leave the counter forever higher than 0 if you use a custom element, but maybe we should have been |
| 20:15 | <shu> | specifically i'm wondering the motivation for not making external scripts increment throw-on-dynamic-markup-insertion as well. too much reasonable code relying on that? |
| 20:17 | <Domenic> | I think external classic scripts are probably untouchable |
| 20:18 | <Domenic> | But outside that invariant I think we have a good amount of freedom |
| 20:18 | <Domenic> | (Also, I think custom elements are probably widely deployed enough that we could not have them permanently disable document.write and friends.) |
| 20:18 | <shu> | i see. well, the proposal from the v8 engineer was to leave ignore-destructive-writes permanently >0 after the first module script tag is executed |
| 20:18 | <shu> | that *does* affect external classic scripts, if a page mixes them |
| 20:18 | <Domenic> | So for example we could switch all module scripts to permanently incrementing the throw counter, if we liked. |
| 20:19 | <shu> | you think that's fine? |
| 20:19 | <Domenic> | Oh, well, I think that's probably fine, if V8/Chrome is willing to risk it. |
| 20:19 | <Domenic> | And my judgment aligns with yours that it's probably rare. |
| 20:19 | <shu> | okay, yeah, i think we're willing to risk |
| 20:21 | <Domenic> | Awesome. So yeah I guess my main contribution is that I'd also be happy if you wanted to use the throw-on-dynamic-markup-insertion counter too. More risk, but more reward. |
| 20:22 | <shu> | trying to track down a use counter for document.write... i was hoping we'd have one |
| 20:23 | <Domenic> | We have document.open() at https://chromestatus.com/metrics/feature/timeline/popularity/2494 |
| 20:23 | <Domenic> | I would expect write() to be >= open() but I am not sure |
| 20:25 | <shu> | quite a lot, though it's the intersection with pages that have module scripts that matter |
| 20:25 | <shu> | doubt we have that level of info |
| 20:26 | <Domenic> | Right |