| 08:28 | <annevk> | Domenic: sorry about the churn on the domain label PR, "nailed it" was not quite correct after all 😅 |
| 08:28 | <Domenic> | All good |
| 08:29 | <Domenic> | I think I'm going to morph https://github.com/whatwg/html/pull/8712 into "nested navigable" -> "navigable" |
| 08:29 | <annevk> | Glad we have CI |
| 08:31 | <Domenic> | Hmm, OK, immediately yak-shaved into getting https://github.com/domfarolino/specfmt compiled and working on my work laptop, cuz this is gonna involve a lot of rewrapping |
| 09:49 | <freddy> | when revising a spec, I noticed that it does variable shadowing. E.g., an algorithm is being passed a document fragment called fragment and a later step is collecting some nodes in a temporary variable also called fragment. Can we assume a separate variable scope for the inner of a loop or is that bad practice? I'll call it tempfragment or such for now.. |
| 09:49 | <Ms2ger> | If you're not immediately sure how it works, maybe you should clarify anyway :) |
| 09:49 | <annevk> | I didn't know about "node navigable". In that light I guess "content navigable" is reasonable. |
| 09:51 | <annevk> | freddy: they are block scoped, but we also don't want you to initialize the same variable multiple times in a single algorithm to avoid such confusion; see https://infra.spec.whatwg.org/#variables |
| 09:54 | <freddy> | uh, is a "for each" loop its own block? |
| 10:06 | <annevk> | freddy: it's somewhat fuzzy as sometimes you can put it on a single line and sometimes not, but it also shouldn't matter in practice |
| 10:06 | freddy | nods |
| 10:06 | <annevk> | Noam Rosenthal: nice work on getting prefetch done \o/ |
| 10:07 | <Noam Rosenthal> | Noam Rosenthal: nice work on getting prefetch done \o/ |
| 12:55 | <annevk> | I didn't realize this, but <div algorithm> essentially scopes variables and if you then end up with a single unscoped variable elsewhere due to an example, it gets flagged. This is rather nice, but also surprising as the error can be in a completely different place from where you expect. |
| 12:56 | <annevk> | TabAtkins: is there something we could do to make Bikeshed from api.csswg.org output the warning/error location, if a location is known? |
| 18:46 | <TabAtkins> | annevk: the error message automatically includes line numbers when I can track what element is causing an error, but I can't always do so easily; iirc the stray-variables spot is one such place. I think I could track it, it would just require a little bit of work. |
| 18:50 | <annevk> | TabAtkins: ah okay, I do recall sometimes seeing them yeah |
| 19:30 | <TabAtkins> | annevk: okay it actually was super easy to refactor that function to track the elements, pushed live now. (I'm p sure the server version is always trunk, not pip, so it should show up in a few minutes.) |