08:50 | <annevk> | Anyone here signed up for bsky.app? I'm @annevk.nl. |
09:29 | <zcorpan> | :target and text fragments only work for the first page load if the element or text is available before onload. If the content is created from a fetch() + script, that can happen after onload. Should we have an explicit API to delay the load event, or to go "try again now to hash-navigate" ? |
09:46 | <annevk> | Hmm, fetch() normally delays the load event as well I think, but of course not if you use it after it. Perhaps what you suggest is okay within some timeout, but it doesn't seem generally okay. |
10:19 | <sideshowbarker> | zcorpan: Given the following WPT test case:
…and given the spec requirements at https://w3c.github.io/html-aam/#img-element-accessible-name-computation — specifically this requirement:
…then it seems that the expectation for that test should be the empty string. |
10:19 | <sideshowbarker> | Or else, is there something I’m misunderstanding? |
10:31 | <Noam Rosenthal> | :target and text fragments only work for the first page load if the element or text is available before onload. If the content is created from a |
10:57 | <annevk> | I think that's possible in theory already as the specification doesn't have network timeouts. But yeah, I'm not entirely convinced the load event is the correct primitive to build more upon. |
11:03 | <zcorpan> | Noam Rosenthal: yes |
11:03 | <zcorpan> | though the "try now" API doesn't |
11:04 | <zcorpan> | annevk: await res.json() doesn't delay |
11:05 | <sideshowbarker> | zcorpan: Ah wait I see: https://w3c.github.io/accname/#step2E says:
… |
11:08 | <zcorpan> | sideshowbarker: somewhat action at a distance |
11:09 | <zcorpan> | annevk: actually where does the spec say to delay the load event for fetch() ? |
12:54 | <annevk> | zcorpan: it's prolly an open issue? At least I was under the impression that most fetches initiated before load fires end up delaying the load event, but maybe fetch() is somehow exempted? |
13:31 | <zcorpan> | annevk: I think https://searchfox.org/mozilla-central/search?q=symbol:_ZN7mozilla3dom8Document13UnblockOnloadEb&redirect=false is relevant for gecko. Includes e.g. fonts but not fetch() afaict |
13:49 | <Noam Rosenthal> | zcorpan: it's prolly an open issue? At least I was under the impression that most fetches initiated before |
13:59 | <annevk> | Noam Rosenthal: I know, but I'm pretty sure we discovered holes in that model |
13:59 | <Noam Rosenthal> | Noam Rosenthal: I know, but I'm pretty sure we discovered holes in that model |
20:19 | <smaug> | jarhar: just looking at the patches... which one defines what select::picker(select) maps to? |
21:13 | <jarhar> | are you talking about the chromium implementation? if so, this is it: https://chromium-review.googlesource.com/c/chromium/src/+/5817433 |
21:26 | <Dominic Farolino> | annevk smaug: We didn't get to it on the WHATNOT agenda today, but we were hoping to discuss graduating moveBefore() to stage 3 — what do you think? I've marked the DOM PR as ready to review. |
21:27 | <smaug> | spec prs |
21:28 | <smaug> | Well, I look at the diff views, and the many prs are split to quite a few diffs |
21:28 | <smaug> | From implementation point of view I need to still check session history handling, that is the most worrisome to me |
21:31 | <smaug> | Like if you have iframes, and you navigate all them multiple times. Now you reorder the iframe elements and load some more pages to them. Then load a new top level page in a way which doesn't put the first top level page to bfcache. Then go back to the first top level page. What gets loaded to which iframe? |
21:45 | <smaug> | Somewhat related to my ancient testcase http://mozilla.pettay.fi/moztests/history2/Start.html Chrome's behavior there is quite surprising, but at least it doesn't load the url to a wrong iframe anymore |
22:31 | <smaug> | Dominic Farolino: hmm, I thought removing mutation events would still block moveBefore. Though that shouldn't block moving to stage 3, only shipping. |
22:58 | <jarhar> | here is the css part https://github.com/w3c/csswg-drafts/pull/10865 |
22:58 | <jarhar> | and here is the html part https://github.com/whatwg/html/pull/10629 |