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:

<img title="title" data-expectedlabel="title" alt="" data-testname="img with tooltip label with empty alt" class="ex" src="data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==">

…and given the spec requirements at https://w3c.github.io/html-aam/#img-element-accessible-name-computation — specifically this requirement:

Otherwise use alt attribute, even if its value is the empty string.

…then it seems that the expectation for that test should be the empty string.
But as you can see, instead the expectation is title (from the title attribute value).
And https://wpt.fyi/results/accname/name/comp_tooltip.html shows that all engines pass that test.
So it seems like they’re all violating that “use alt attribute, even if its value is the empty string” spec requirement.

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 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" ?
Wouldn't this allow delaying the load event indefinitely and various similar footguns?
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:

E. Host Language Label: Otherwise, if the current node's native markup provides an attribute (e.g. alt) or element (e.g. HTML label or SVG title) that defines a text alternative, return that alternative in the form of a flat string as defined by the host language, unless the element is marked as presentational (role="presentation" or role="none").

<img alt=""> is role="presentation"

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 load fires end up delaying the load event, but maybe fetch() is somehow exempted?
In HTML this is explicitly specified for each operation that delays the load event, there's nothing general for fetches
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
OK gotcha
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