| 07:39 | <JakeA> | littledan: we've always felt that putting a service worker install step ahead of navigation is something we want to avoid |
| 07:39 | <JakeA> | It could easily put a few 100k ahead of the first html response byte |
| 07:39 | <JakeA> | well, request byte |
| 10:37 | <littledan> | JakeA: Does this extend to running other kinds of setup scripts at the beginning of page load, as indicated by, e.g., a Response header? |
| 10:39 | <littledan> | JakeA: Is there a written explanation of this somewhere? Or would you maybe be available to get in touch with someone who does have a proposal of this type, with the motivation that putting in a response header is easier in practice to deploy than adding a prefix to the html (apparently, people get the ordering wrong in practice) |
| 10:40 | <littledan> | This is for https://github.com/privacycg/proposals/issues/3 |
| 10:42 | <JakeA> | littledan: <script> is blocking by default, and it feels like it's been the source of web performance issues for decades since. https://github.com/WICG/import-maps#installation for instance recommends against external import-maps, but there are also lots of articles against blocking scripts, like http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/ |
| 10:42 | <JakeA> | I'll take a look at the issue |
| 10:43 | <JakeA> | Part of the problem is we never really figured out how to make H/2 push work |
| 10:43 | <littledan> | :( |
| 10:43 | <littledan> | specifically I'm referring to Trust-Label-Script: |
| 10:43 | <littledan> | I was wondering if Origin Policy could help, since you then could move that fetch a bit earlier |
| 10:44 | <littledan> | there's also the possibility of some built-in policies. But it looks like Trusted Types started with this and then moved away from it. |
| 10:45 | <littledan> | it seems like this script would have to run before other scripts do, but it wouldn't have to block parsing the HTML document or fetching and parsing the scripts, just executing them |
| 10:46 | <JakeA> | When is the origin policy fetched? |
| 10:46 | <JakeA> | Ahh I see, it gets it if the response has a particular header |
| 10:51 | <JakeA> | littledan: I've just skim-read this, so I might be wrong, but it seems like this thing only impacts other script execution, right? That means the Trust-Label-Script would need to be executed before other script, but it doesn't need to block html & css rendering |
| 10:51 | <littledan> | JakeA: That's my understanding as well |
| 10:53 | <JakeA> | littledan: That seems less bad. It blocks the execution of script, but not the loading of script (you'd still be able to fetch a whole module graph right? That doesn't count as execution) |
| 10:54 | <littledan> | JakeA: Right, though I wonder if it might be a little more linearizing in current implementations, unless there's a big refactoring |
| 14:02 | <JakeA> | I've just seen a spec using https://heycam.github.io/webidl/#this rather than https://dom.spec.whatwg.org/#context-object. Are they equivalent? Should 'context object' be considered deprecated in specs? |
| 14:16 | <Domenic> | JakeA: yes and yes. It'd be nice if we could update DOM and kill context object... |
| 14:18 | <JakeA> | Domenic: mind if I make a PR to the DOM spec that replaces internal usage, and adds a note to the [=context object=] definition to suggest it's deprecated? |
| 14:18 | <Domenic> | JakeA: sounds great to me, although I'd kind of prefer removing the dfn entirely and then causing all the consumers to update. |
| 14:19 | <JakeA> | Domenic: I'll do that. I just figured that, given how much it's used, it might be 'cruel' to just get rid of it. I'll get rid of it and we can discuss in the PR |
| 14:20 | <Domenic> | Perfect, yeah |
| 14:20 | <Domenic> | Will be good to get annevk's opinion too, as DOM editor. |
| 14:21 | <annevk> | I'm supportive of moving away from it, I'm not sure how much downstream usage there still is though, would be good to find out before removing completely |
| 14:22 | <annevk> | I know some refactoring work I was doing in Encoding got blocked on an IDL style question that still isn't resolved |
| 14:22 | <JakeA> | It's used loads in service worker and background fetch, that much I know 😀 |
| 14:25 | <TabAtkins> | I really need to dust off and finish the backref-tracking code... |
| 14:27 | <TabAtkins> | Oh weird, looks like the set of specs I'm relying on currently is "what's in Bikeshed's testsuite". I know that's not a super-informed choice, but I wonder if it is good enough. |
| 15:06 | <JakeA> | Another request to drop manual text wrapping from specs |
| 15:08 | <annevk> | Yeah, it's quite a drain on productivity, we really ought to automate it or change the rules |
| 15:08 | <TabAtkins> | Or switch to the Morally Correct semantic linewrapping. |
| 15:09 | <TabAtkins> | (i'm fine with either in the specs i edit, just so long as it's not an XXchar limit) |
| 15:09 | annevk | retreats |
| 15:17 | <JakeA> | TabAtkins: Is there a way to mark a definition as deprecated, so bikeshed will warn if it's used but not fail? |
| 15:17 | <TabAtkins> | Hm, not really. You can mark it not exported, but that'll make it fail. |
| 15:17 | <TabAtkins> | That's definitely something I'd be happy to add tho. |
| 15:17 | <JakeA> | I'll file it |
| 15:17 | <TabAtkins> | danke |
| 20:02 | <eeeps> | annevk: if you could find some time to chat about https://github.com/whatwg/html/pull/5112#discussion_r370326608, clearly I... need help |
| 21:15 | <annevk> | eeeps: European office hours would be ideal |