| 13:43 | <FND> | hey, I have a bit of an off-topic question: |
| 13:44 | <FND> | would it be correct to claim that in the past, a regular page transition (as in link) resulted in a blank page before the new page was loaded |
| 13:44 | <FND> | and that this is no longer the case with modern browsers? |
| 13:44 | <FND> | (the background here is just letting the browser handle navigation vs. pjax-style optimizations) |
| 13:51 | <FND> | as in: I seem to recall the process used to be |
| 13:51 | <FND> | click link → draw about:blank → request → response → draw new page |
| 13:52 | <FND> | and that second step is now skipped, resulting in less jarring visuals - am I fantasizing? |
| 14:15 | <Domenic> | FND: there was never such a second step |
| 14:15 | <Domenic> | What you are likely noticing is that your internet connection has gotten faster |
| 14:16 | <Domenic> | So the amount of time that the browser spends displaying `<html><head>... a bunch of stuff that doesn't cause the screen to be anything interesting ...` is decreased |
| 14:16 | <FND> | I didn't literally mean "visit about:blank", more "clear the screen before _starting_ the request" - but that's not the case either? |
| 14:16 | <FND> | let me check with throttling (again) |
| 14:16 | <Domenic> | Indeed, no |
| 14:17 | <FND> | I'm glad I asked before propagating lore - thanks for setting me straight |
| 14:19 | <FND> | so, I just made Slack (the slowest thing I could think of) reload, in the browser of course: |
| 14:19 | <FND> | it _looks_ to me that even with a slow connection, the previous state persists until the new one is ready to replace it |
| 14:21 | <FND> | oh, that's probably a service worker lying to me |
| 14:21 | <andreubotella> | browsers don't start building the DOM until they've gotten 1024 bytes of a response, due to encoding sniffing |
| 14:24 | <FND> | I guess it's just a lot more complicated than my mental model accounted for |
| 14:25 | <FND> | so I gotta find a different way to convince folks that letting the browser handle page transitions (by default anyway) makes for decent UX |
| 14:45 | <annevk> | I think there have been changes (and there continue to be) to how much work is done on the next document before making the switch |
| 14:51 | <FND> | that's a bit of a relief, so at least I'm not fantasizing _all_ of it |
| 14:52 | <FND> | you don't happen to have some sort of link? |
| 14:52 | <FND> | (I realize much of this is probably engine-specific optimizations which are subject to change etc.) |
| 14:58 | <annevk> | Not really, "page load" might yield some results in bug databases, but couldn't find anything useful quickly |
| 14:59 | FND | nods |
| 14:59 | <FND> | thanks though, that's already useful |
| 15:00 | FND | looks up CMOS citation styles for IRC quotes |
| 16:27 | <annevk> | Domenic: whatwg/fetch Streams PR still has a TODO |
| 16:28 | <Domenic> | annevk: it can't be resolved in a single commit. |
| 16:28 | <Domenic> | i.e. we need to merge the PR, then fix that TODO after the linking databases pick up the change. |
| 16:29 | <annevk> | Domenic: I see |
| 16:29 | <annevk> | Domenic: who else is claiming resolve? |
| 16:30 | <Domenic> | annevk: something in CSS IIRC, let me check... |
| 16:30 | <Domenic> | Hmm, spec:fileapi-1; type:dfn; text:resolve |
| 16:31 | <Domenic> | https://github.com/w3c/FileAPI/blob/4c4628dcfe3e2d97b3050dc995592a9716a166df/index.bs#L1532 hmm |
| 16:31 | <Domenic> | Maybe an old CR or something |
| 16:32 | <annevk> | Still there |
| 16:32 | <Domenic> | But it has for="" |
| 16:32 | <Domenic> | I guess maybe that just means it should be [=/resolve=]? |
| 16:33 | <annevk> | Domenic: yeah, I think if you use for=/ in whatwg/fetch it'll be fine |
| 16:33 | <annevk> | Domenic: or for=promise if that's what IDL uses, dunno |
| 16:33 | <Domenic> | I checked, IDL has no for="" |
| 16:33 | <annevk> | Domenic: then use for=/ |
| 16:34 | <annevk> | Not that File API should use that term for that... |
| 16:34 | <Domenic> | done |
| 16:35 | <Domenic> | If we turned on https://tabatkins.github.io/bikeshed/#metadata-assume-explicit-for then this would work more like what I expect |
| 16:35 | <Domenic> | I believe it might have been added for me, in fact |
| 16:36 | <TabAtkins> | Yup |
| 16:36 | <annevk> | I'm not opposed, but a bunch of our specs will require massive changes for that |
| 16:36 | <Domenic> | Yeah, we probably would want to experiment locally a bit |
| 17:14 | <shu> | annevk: Domenic: have y'all happened to come to a decision on https://github.com/whatwg/html/issues/5640#issuecomment-650254713? |
| 17:14 | <Domenic> | We haven't discussed, but I still prefer (2) |
| 17:20 | <shu> | understood. i'd like to know if i should put something on the TC39 agenda by end-of-week. abstaining from a strong opinion on the approach |
| 17:38 | <annevk> | shu: I don't feel strongly; I'm a bit concerned about adding cache keys, but the alternative is rather involved as well |
| 18:00 | <shu> | annevk: that’s fine, but i’d still like a decided direction from both you and domenic to keep things moving in tc39 as well |
| 18:01 | <Domenic> | shu: please put it on the TC39 agenda |
| 18:01 | <shu> | wfm, thanks |