| 00:25 | <Sam Sneddon [:gsnedders]> | In principle basically every case should've been defined in CSS1 (but probably wasn't): https://www.w3.org/TR/REC-CSS1/#forward-compatible-parsing |
| 16:46 | <annevk> | emilio: I'd appreciate if you could review https://github.com/whatwg/html/pull/7361 as well, it looks fine editorially, but I'm not a 100% comfortable with the focus algorithms |
| 16:47 | <emilio> | annevk: will try to get to it today, thanks (and btw sorry but I can't make it to the new triage meeting time today, conflict :/) |
| 16:49 | <annevk> | Understandable, it's not ideal for Europe to begin with 🙂 |
| 18:42 | <miketayl_r> | i'm not good at bay area geography, is europe north bay or south bay? |
| 19:02 | <TabAtkins> | all of europe is north sea |
| 19:06 | <TabAtkins> | tho another answer is that the north/south bay divide is probably right around 37°37′, which means all but the southernmost tips of spain, italy, and greece are north bay |
| 19:07 | <TabAtkins> | turkey actually has some non-trivial south bay population |
| 19:12 | <annevk> | miketayl_r: Sausalito? Kinda |
| 19:13 | <annevk> | Also where does that leave Boston? |
| 20:36 | <miketayl_r> | just past Berkeley, i think |
| 21:19 | <Mattias Buelens> | @domenic I believe we should also file spec bugs with Firefox and Safari for the changes to default readers in https://github.com/whatwg/streams/pull/1168 ? That PR affects _both_ default and BYOB readers. |
| 21:20 | <Domenic> | @domenic I believe we should also file spec bugs with Firefox and Safari for the changes to default readers in https://github.com/whatwg/streams/pull/1168 ? That PR affects _both_ default and BYOB readers. |
| 21:20 | <Mattias Buelens> | All right 🙂 |
| 21:27 | <Luca Casonato> | Would it be a huge deal of extra work for you all to also open implementation issues on Deno and Node repos for spec changes in whatwg/streams? Just a simple "heads up: this thing is changing" with a link to the PR, or a "cc @lucacasonato @jasnell" on relevant PRs would be very awesome :-) |
| 21:28 | <Mattias Buelens> | Would it be a huge deal of extra work for you all to also open implementation issues on Deno and Node repos for spec changes in whatwg/streams? Just a simple "heads up: this thing is changing" with a link to the PR, or a "cc @lucacasonato @jasnell" on relevant PRs would be very awesome :-) |
| 21:28 | <Luca Casonato> | Thank you :-) |
| 21:29 | <Mattias Buelens> | Would be nice to make this part of our process some day, see https://github.com/whatwg/streams/issues/1141 |
| 21:30 | <Luca Casonato> | Ah cool - if I ever have some free time (hahahaha), I can give this a shot. |
| 21:33 | <Andreu Botella (he/they)> | I'm already familiar with the spec-factory infrastructure, it shouldn't take me too long |
| 21:44 | <Luca Casonato> | too late, i already did it |
| 21:44 | <Luca Casonato> | apparently i can "free" time for useful things :D |
| 21:50 | <Luca Casonato> | https://github.com/whatwg/spec-factory/pull/35 <- here we go |
| 21:56 | <Mattias Buelens> | Looks good! For completeness, maybe we can also update https://github.com/whatwg/meta/blob/main/MAINTAINERS.md#handling-pull-requests with links on where to file Node and Deno issues? 🙂 |
| 21:56 | <Luca Casonato> | Already opened a PR 5 minutes ago :-) https://github.com/whatwg/meta/pull/238 |
| 21:56 | <Mattias Buelens> | I'm too slow :P |
| 22:27 | <mgaudet> | Question about streams specification; I was looking at an older chrome security bug. Some cursory testing suggests that in addition to the chrome change, it has been fixed at the specification level. Nevertheless, I'm wondering: For lists being iterated where calling into user-defined code, does it make sense to change the specification to adopt a similar policy to the chrome change (move the list into a local, iterate the local instead). Defensively I think it makes sense for our implementation, but I'm not sure how this is looked at from a specification perspective. |
| 22:33 | <Mattias Buelens> | Well, exactly that was just landed in https://github.com/whatwg/streams/pull/1168. 😛 We now move the list into a local variable first before we iterate it. This turned out to be necessary for the correctness of the async iterator steps (see comment). |
| 22:35 | <mgaudet> | (Github has those links broken, but I found the conversation). Nice! Looks like I'm ahead of the game for once |