00:09
<Domenic>

Domenic: instead of navigator.pushManager should it be window.pushManager for https://github.com/w3c/push-api/pull/368? I vaguely recall some desire to deprecate the former, though Navigator also currently states

They also serve as a generic global under which various APIs are located in this and other specifications.

so maybe I misremember?

My opinion is encapsulated here: https://github.com/w3ctag/design-principles/issues/448#issuecomment-2219295220 . I don't know the full details of pushManager but I would guess it falls under my "Perhaps-borderline examples, but I think Navigator was the wrong choice: [...] OS APIs that are sufficiently abstracted over by a web standard (clipboard, virtualKeyboard)"
00:10
<Domenic>
I didn't realize we had that statement about Navigator in the spec. That's a bit unfortunate in my opinion.
00:11
<Domenic>
What is the right action for the participant agreement check in https://github.com/whatwg/html/pull/10547 ? canadahonk was Mozilla employee when he authored it, but is not anymore.
Umm I think we could technically merge with an override (i.e. a comment, maybe both on the PR and the commit itself, explaining the situation). If canadahonk was willing to sign as an individual though that would be nice.
02:09
<sideshowbarker>
annevk: FYI https://github.com/web-platform-tests/wpt/issues/49249
10:59
<annevk>
Domenic: pushManager is not established precedent just yet (it's only on ServiceWorkerRegistration to date). I can move it to Window for Declarative Web Push.
11:04
<annevk>
sideshowbarker: commented. Test seems correct, albeit confusing and not necessarily testing the intended thing. Although I guess it hit something in Ladybird / Chromium...
12:21
<freddy>
Domenic: What is my hope for https://github.com/whatwg/html/issues/8013 seeing some updates? :)
14:41
<Shannon Booth>

Hello! I have been trying to debug an issue in Ladybird's implementation of https://github.com/web-platform-tests/wpt/blob/master/url/data-uri-fragment.html

The issue in Ladybirds implementation is that the script is running .matches(':target') before the document has populated it's target element. I know of a way to 'fix' it, but I'm having trouble figuring out how the spec intends this to be done. From what I can gather, the entry point of this is maybe somewhere around here: https://html.spec.whatwg.org/multipage/browsing-the-web.html#scripts-may-run-for-the-newly-created-document

But "try to scroll the fragment" won't guarantee that the target element is set before that script can be run. And if I am understanding navigables right, it wouldn't be a navigation to a fragment either which does have "scroll to the fragment" in it. Would anyone be able to point me to the right direction of how the spec achieves updating the target element before the script is able to query it?

14:48
<Shannon Booth>
There look to be some steps which delay the load event for certain stylesheets, but I couldn't spot any criteria which would be relevant there
23:55
<Kayla Beezy>
I need help deleting some storage space off my disk