07:30
<annevk>
Domenic: I was looking at https://github.com/web-platform-tests/wpt/pull/21041 again and I think they match implementations, but not the spec. The spec grabs the document when calling parseFromString(). But implementations (and the tests) assume it's grabbed as part of the DOMParser invocation.
07:31
<annevk>
Domenic: I prototype'd the spec in https://github.com/WebKit/WebKit/pull/22971 and got a number of test failures.
07:33
<annevk>
There's also some differences across implementations from code inspection. Only Gecko seems to carry over the base URL. And Gecko caches the URL when DOMParser is constructed. So pushState() doesn't impact it. (This fails some tests, though a design like that might be simpler in certain ways.)
07:34
<Domenic>
Hmm, good catch. Strange that I added tests specifically for this sort of multi-global madness but didn't match the spec when doing so.
07:44
<Domenic>
Domenic: I was looking at https://github.com/web-platform-tests/wpt/pull/21041 again and I think they match implementations, but not the spec. The spec grabs the document when calling parseFromString(). But implementations (and the tests) assume it's grabbed as part of the DOMParser invocation.
Wait, no, I think the tests match the spec. "this's relevant global object's associated Document" is equivalent to the global at the time new DOMParser() was called; new DOMParser() creates this.
07:44
<Domenic>
Your patch prototypes using the current global object's associated Document, which is not what the spec says.
07:49
<annevk>
Domenic: interesting, thanks! So whenever we use relevant I guess we implicitly require the implementation to store a reference in the constructor. I guess that makes sense.
07:52
<Domenic>
Yeah, I kind of thought all implementations already did that? Web IDL certainly assumes it.
07:53
<Domenic>
At least a reference to the global, from which you can get the document
07:54
<annevk>
Domenic: It looks to be manual in all three implementations. Chromium and WebKit even use a WeakPtr which worries me a little bit, but it's hard to force GC in tests so not sure if my concerns are well-founded.
07:55
<Domenic>
Hmm yeah, in Chromium there's a variety of easy utility classes and templates you can inherit from I guess, but that makes sense.
07:55
<annevk>
Or maybe there's just some leftover code in DOMParser that's redundant with more recent IDL developments?
10:47
<sideshowbarker>
I see that https://github.com/WICG/identity-credential/blob/main/digital-credentials-2-proposal.md (frontend web-platform API for “Digital Credentials”) seems to have gotten some implementor interest. I don’t really know much of anything about credentials/identity stuff, except some incidental awareness of the W3C Verifiable Credentials and Decentralized Identifiers (DID) stuff — and only then, because the groups working on those things are at the W3C. So is the implementor interest in WICG Digital Credentials also an indicator that implementors now see W3C Verifiable Credentials (and maybe DID also) as something actually possibly relevant for the web platform? I’ve gleaned that W3C Verifiable Credentials are just one possible data format for Verifiable Credentials — and the WICG Digital Credentials draft cites a protocol spec at https://openid.net/specs/openid-4-verifiable-presentations-1_0.html which mentions W3C VC but also an “ISO mdoc” data format that seems to be for basically the same thing. Anyway, I’m basically just wondering whether there’s now actually enough browser-implementor interest in this stuff — in integrating it into the web platform through frontend APIs — that I should actually start paying attention to any of it.
14:02
<hsivonen>
How come https://url.spec.whatwg.org/ isn't WHATWG green?
14:05
<Ms2ger>
Refresh? There was a CI issue earlier
14:05
<hsivonen>
Refresh? There was a CI issue earlier
Doesn't help. I guess there's a sticky cache somewhere.
14:05
<Ms2ger>
I was seeing green from my own cache. Probably the build step needs to run again
14:07
<Ms2ger>
cc annevk
15:08
<annevk>
Yeah, Domenic and I should deploy some spec-factory changes. But also, turns out i18n-glossary is at it again squatting on UTF-8 making it impossible to build the URL Standard: https://github.com/w3c/i18n-glossary/issues/66 :/
18:13
<annevk>
I had missed that Gecko now passes most URL tests. Nice work!