| 09:08 | <annevk> | Domenic: is https://github.com/whatwg/html/pull/8467 in your queue? |
| 09:10 | <Domenic> | Domenic: is https://github.com/whatwg/html/pull/8467 in your queue? |
| 09:10 | <annevk> | Domenic: let me rephrase that, do you want to look at it before it lands? |
| 09:10 | <annevk> | Since you reviewed it before. |
| 09:12 | <Domenic> | Nah, seems fine. Although I'm not sure it actually has Chrome support at the moment. |
| 09:15 | <annevk> | Chrome engineers drove the change with the CSS WG. If you want to double check on that I can hold off on landing this. Let me know. |
| 09:18 | <Domenic> | Yeah we should hold off. They're failing to get signoff on blink-dev last I saw. |
| 11:58 | <annevk> | keithamus: I'm gonna wait with another round of review for EventTarget until it's a bit more established what the API shape should be. One thing that did seem to be missing is the parent setter/getter definition. |
| 11:59 | <keithamus> | annevk: within EventTarget? or EventTargetInternals? |
| 12:08 | <keithamus> | I've updated which hopefully clarifies the steps for get/set on EventTargetInternals parent. |
| 13:16 | <annevk> | Jake Archibald: I cannot reply to https://twitter.com/jaffathecake/status/1711872418434654419 but isn't the problem Chromium here, perhaps? I wonder what happens in the non-Chromium URLPattern implementation. Custom URL schemes are supported pretty well in URL and the idea is that they are too in URLPattern, provided you have a compliant URL parser. |
| 13:18 | <Jake Archibald> | annevk: ohhh, my understanding was that if you use a non http(s) scheme then the rest of the URL won't be parsed by HTTP rules |
| 13:22 | <annevk> | Jake Archibald: see https://jsdom.github.io/whatwg-url/ as an easy way to test specific inputs; generally when people complain about this they are talking about a long-standing Chromium and Gecko bug |
| 13:22 | <annevk> | I was hoping that Interop 2023 would fix it, but it seems like it will be at least another year |
| 13:39 | <annevk> | Domenic: is https://github.com/whatwg/fetch/issues/1715 in your queue? |
| 13:41 | <Domenic> | Domenic: is https://github.com/whatwg/fetch/issues/1715 in your queue? |
| 13:49 | <annevk> | Domenic: in particular I asked feedback on the name, not the whole API |
| 13:50 | <annevk> | Domenic: are you no longer reading GitHub pings? |
| 17:51 | <jub0bs> | * The guy (who has a huge audience on Twitter and YouTube) wants to talk about
|
| 17:51 | <jub0bs> | * The guy (who has a huge audience on Twitter and YouTube) wants to talk about
|
| 18:08 | <jub0bs> | * The guy (who has a huge audience on Twitter and YouTube) purports to explain
|
| 20:00 | <jub0bs> | * Nothing but pointless drivel so far... |
| 20:59 | <Dominic Farolino> | If a request from a document goes through a service worker, what's the client set to of the request that finally makes it to the "HTTP-network-or-cache fetch" algorithm (assuming the service worker did a respondWith(fetch(e.request))? Is it the original document's ESO, or the service worker's? After reading https://w3c.github.io/ServiceWorker/#on-fetch-request-algorithm I'm almost positive the answer is "the original document global". |