| 07:26 | <foolip> | Domenic: I think there's a bug in https://html.spec.whatwg.org/#HTMLAllCollection-call |
| 07:26 | <Domenic> | noooo |
| 07:26 | <foolip> | just a small one |
| 07:26 | <foolip> | what should document.all(undefined) do? |
| 07:26 | <foolip> | Unless there's something is JS that I don't know about, these "custom bindings" need to handle it to be consistent with document.all.item(undefined), right? |
| 07:27 | <Domenic> | I don't know if consistency is the goal |
| 07:27 | <Domenic> | The goal was matching browsers IIRC |
| 07:27 | <Domenic> | I think we covered this case... |
| 07:27 | <foolip> | Domenic: you're right, that'd be fine, but Safari now passes a test that contradicts the spec on this point |
| 07:28 | <othermaciej> | do other browsers fail the test? |
| 07:28 | <Domenic> | So apparently it was intentional to make it return the element with ID "undefined" https://github.com/whatwg/html/pull/2932#issuecomment-327085227 |
| 07:28 | <foolip> | It's the "legacy caller with undefined" one in https://wpt.fyi/html/infrastructure/common-dom-interfaces/collections/htmlallcollection.html, although the Safari run there is busted (bug filed yesterday) |
| 07:29 | <Domenic> | I wish wpt.fyi were reliable :( |
| 07:29 | <foolip> | Domenic: it will be! |
| 07:29 | foolip | fails to find anyone at Bocoup to poke right here :) |
| 07:29 | <Domenic> | It's been hyped for so long, I look forward to the day it's usable |
| 07:29 | <othermaciej> | too bad there is no Edge result there |
| 07:30 | <othermaciej> | (Though I don't know if there are ven to be most trusted on the most compatible document.all emulation) |
| 07:30 | <foolip> | "Make document.all.item(undefined)" huh, that's not what I get by just trying to implement the spec though |
| 07:30 | <Domenic> | The tests basically don't seem to match the spec PR |
| 07:30 | <foolip> | How could it, given the "(HTMLCollection or Element)? item(optional DOMString nameOrIndex)" IDL? |
| 07:31 | <Domenic> | Hmm right I'm confused and maybe that post is confused |
| 07:31 | <Domenic> | Sigh maybe trying to decipher our intent here is stupid and we should try to figure it out from compat matrices again |
| 07:32 | <foolip> | The addition in https://github.com/whatwg/html/pull/2932/commits/ec03b38df55f8fddf115d9c704babd0710966ccc that would have made it so seems to not have been landed |
| 07:33 | <Domenic> | OK so I think your original diagnosis was right |
| 07:33 | <Domenic> | The [[Call]] should be consistent with item() |
| 07:33 | <Domenic> | https://github.com/whatwg/html/commit/0679448c59cb4cd69019be1e1f35fee1bcbc9c66 was supposed to be editorial |
| 07:33 | <Domenic> | But it didn't take care of aligning document.all(undefined) with document.all.item(undefined) |
| 07:34 | <foolip> | Domenic: https://wpt.fyi/html/infrastructure/common-dom-interfaces/collections/htmlallcollection.html?sha=13eaad17a4 had good runs for Edge and Safari |
| 07:35 | <Domenic> | So like a 2/2 split it looks like |
| 07:35 | <foolip> | Domenic: I have a fix I'm about to send, saying "If argumentsList's size is zero, or if argumentsList[0] is undefined, return null." |
| 07:35 | <Domenic> | But we went with Safari because they'd been keeping up to date with spec updates and we didn't want to keep churning them |
| 07:35 | <Domenic> | Yes that sounds perfect |
| 07:35 | <foolip> | Is that a coherent say to thing, or does JS do something? |
| 07:38 | <foolip> | Domenic: https://github.com/whatwg/html/pull/3392 (commit message a bit rushed, feel free to nitpick) |
| 07:39 | <annevk> | Given that the time from "there's a bug to PR" is rather short, maybe give it a day before merging? |
| 07:40 | <Domenic> | I dunno seems like a straightforward regression fix |
| 07:40 | <annevk> | nm |
| 07:40 | <foolip> | annevk: I'm not in a rush if you want to ask someone |
| 07:40 | <annevk> | Nah, I'm just scared of document.all |
| 07:41 | <foolip> | This is from me reviving my old change to match the spec to be able to forget about it forever, when I found that legacycaller was gone and custom bindings still needed :) |
| 07:43 | <annevk> | Whoa, Promise.prototype.finally |
| 07:43 | <Domenic> | The good news is that legacycaller is gone from everywhere else that would need it, like object and embed |
| 07:48 | <foolip> | Domenic: looks like that's even true in Blink actually, amazing |
| 08:21 | foolip | removes remaining traces: https://chromium-review.googlesource.com/c/chromium/src/+/883002 |
| 10:54 | <smaug____> | annevk: do you happen to know which spec might refer to "add a PerformanceResourceTiming entry" in https://w3c.github.io/resource-timing/#idl-def-performanceresourcetiming |
| 10:54 | smaug____ | wonders what sync event dispatch there |
| 10:57 | <smaug____> | s/what/that/ |
| 10:59 | <annevk> | smaug____: all I know is that WG routinely does bad layering so I'm not surprised |
| 10:59 | <smaug____> | yeah |
| 10:59 | <smaug____> | I'm trying to figure out what should happen for example with sync XHR |
| 11:02 | <annevk> | smaug____: file an issue? |
| 11:02 | <smaug____> | yeah, just writing it |
| 11:02 | <annevk> | smaug____: it seems like that should be integrated with XHR or Fetch somehow and I know for a fact it's not |
| 11:02 | <annevk> | smaug____: apparently they also uniquely identified XHR despite nothing else in the networking stack doing so :/ |
| 11:03 | <annevk> | smaug____: I've yet to complain though, still working through review / issues I wanted to tackle yesterday |
| 11:04 | <yoav> | annevk & smaug____: please file issues |
| 11:04 | <smaug____> | yoav: these specs are so... unimplementable |
| 11:05 | <smaug____> | implementations seem to be full of guesswork |
| 11:05 | <annevk> | yoav: I wish whoever wrote these specs would file issues as you're supposed to do when you monkey patch all the things |
| 11:05 | <yoav> | we've inherited that spec along with its tech debt. Currently figuring out who can dedicate time to work on open issues |
| 11:05 | <annevk> | yoav: having to find out someone added yet more junk to XHR in 2018 is not great |
| 11:06 | <yoav> | https://github.com/w3c/resource-timing/milestone/2 |
| 11:06 | <yoav> | Is the XHR stuff a recent addition/ |
| 11:06 | <yoav> | ? |
| 11:06 | <annevk> | I have no idea, but I learned about it a couple hours ago |
| 11:07 | <annevk> | Which is weird, being the maintainer of XHR for over a decade |
| 11:08 | <yoav> | annevk: I'm guessing you're referring to the `initiatorType` |
| 11:09 | <annevk> | yoav: yeah! |
| 11:09 | <yoav> | Feels like something that can be fixed, as initiatorType is extremely broken and inconsistent |
| 11:09 | <yoav> | I want to kill it and create an "initiator" that is (at least roughly) based on Request.destination |
| 11:10 | <yoav> | but for that we need to fix all the L2 bugs first... |
| 11:11 | <yoav> | annevk: unrelated, if a Link header has a relative URL, what URL is that relative to? |
| 11:11 | <yoav> | The document or the resource? |
| 11:12 | <yoav> | https://tools.ietf.org/html/rfc5988#section-5.1 seems relevant |
| 11:12 | <yoav> | Note that any base IRI |
| 11:12 | <yoav> | from the message's content is not applied. |
| 11:12 | <yoav> | but I don't understand what "Note that any base IRI from the message's content is not applied." |
| 11:13 | <yoav> | actually means |
| 11:13 | <yoav> | (sorry for the copy/paste shenanigans) |
| 11:13 | <yoav> | I think it refers to <base href> |
| 11:13 | <yoav> | but not sure |
| 11:14 | <yoav> | and not clear what to do if the Link header is on a subresource |
| 11:21 | <yoav> | https://github.com/w3c/resource-timing/issues/142 |
| 11:22 | <annevk> | yoav: I'd use the same as the Location header |
| 11:22 | <yoav> | where is that defined? |
| 11:22 | <annevk> | yoav: 5.3 of https://fetch.spec.whatwg.org/#concept-http-fetch |
| 11:23 | <annevk> | yoav: you probably need to consider service workers somehow and actually define when Link gets parsed |
| 11:23 | <yoav> | OK, so relative to the subresource URL? |
| 11:23 | <annevk> | yoav: message contents would indeed be <base> |
| 11:24 | <annevk> | yoav: yeah, I'm not entirely sure what that means for synthetic responses atm |
| 11:25 | <yoav> | what do you mean by "synthetic responses"? |
| 11:26 | <annevk> | yoav: new Response() |
| 11:27 | <yoav> | ko |
| 11:27 | <yoav> | ok |
| 11:29 | <yoav> | intuitively, seems like that would depend on the Request the Response is sent on |
| 11:32 | <yoav> | annevk: Does a step before 5 in the HTTP fetch concept make sense for such processing? |
| 11:34 | <annevk> | yoav: yeah seems reasonable |
| 12:46 | <annevk> | yoav_: thanks for filing that issue, added a comment |
| 14:53 | <annevk> | <canvas> is such a mess |
| 14:53 | <annevk> | I hope nobody uses it as a copy-and-paste template |
| 14:54 | <annevk> | I wish Ms2ger never filed those issues so I could have stayed ignorant |
| 14:54 | <Ms2ger> | I'm going to interpret that as a compliment :) |
| 14:58 | <annevk> | Sigh, and the checks createPattern and createImageBitmap do are not quite equivalent |
| 14:59 | <annevk> | Although maybe that's doable still |
| 15:39 | <gsnedders> | Can someone else add themself as an owner in wpt for canvas BTW? |
| 15:43 | <annevk> | Wait only Safari supports OffscreenCanvas? |
| 15:44 | <annevk> | Maybe that makes sense given that Safari was first with <canvas> too |
| 15:47 | <gsnedders> | annevk: I didn't think Safari supported it? Chrome does, behind flag, and Firefox does, behind flag, WebGL only |
| 15:48 | <annevk> | Per https://webkit.org/blog/8039/release-notes-for-safari-technology-preview-45/ it does, but only webgl |
| 15:49 | <annevk> | And also per my local testing, which is always extremely reliable... |
| 15:50 | <annevk> | You can trust me since I once got paid to do QA |
| 15:58 | <gsnedders> | :) |
| 16:11 | <Ms2ger> | annevk, that matches the code I've read |
| 16:12 | <Ms2ger> | Igalia is working on 2d support, I believe |