| 03:44 | <Domenic> | Dark mode styles are being deployed. Seems that on non-HTML, this is causing us to get W3C colors temporarily. Hopefully this will stop once the bikeshed-boilerplate stuff propagates through the ecosystem? |
| 04:28 | <Domenic> | Yeah, not clear how often api.csswg.org gets updated, but until it gets the latest bikeshed update, we have W3C colors on all WHATWG specs :( |
| 04:30 | <Domenic> | If we want to resurrect https://github.com/whatwg/spec-factory/pull/42 and https://github.com/whatwg/whatwg.org/pull/404/ we could fix I guess |
| 07:50 | <Kaiido> | Looks like https://resources.whatwg.org/standard.css uses a few hard-coded colors that don't really match with the dark-mode? The ones I spotted are .element (which is particularly outstanding), and the top links of the full page #head nav > div > a[...]. There a few others but they seem less problematic (like figure.diagrams). |
| 09:50 | <Domenic> | Looks like https://resources.whatwg.org/standard.css uses a few hard-coded colors that don't really match with the dark-mode? The ones I spotted are |
| 09:57 | <Domenic> | TabAtkins: sorry to ping while you're on vacation, but any idea how often the CSSWG API server runs bikeshed update to pull in new boilerplates? |
| 10:00 | <annevk> | I thought that was instant. But you might have to trigger builds for each standard? |
| 10:00 | <Domenic> | No, it's not instant |
| 10:00 | <Domenic> | It may pull in new bikeshed releases, but it doesn't do bikeshed update |
| 10:00 | <Domenic> | We will also need to trigger new builds, but only after the CSSWG API updates |
| 10:01 | <Domenic> | (You can test this by running make remote locally on any spec; you get one with the wrong boilerplate. Whereas if you run bikeshed update; make local, you get the right boilerplate.) |
| 10:01 | <annevk> | I think the problem is that Tab didn't generate new manifest files |
| 10:01 | <Domenic> | That's done automatically |
| 10:01 | <annevk> | Maybe I can fix that |
| 10:01 | <annevk> | No it's not |
| 10:01 | <annevk> | See commit history: https://github.com/speced/bikeshed-boilerplate/commits |
| 10:01 | <Domenic> | https://github.com/speced/bikeshed-data/commit/9cab061e5d6c9cfffd1771698848379acfad5367 |
| 10:02 | <Domenic> | Hmm I wonder what the difference between the two manifest.txt files is |
| 10:05 | <annevk> | The script fails for me with a syntax error... |
| 10:05 | <Domenic> | Python 2 vs. 3? Or 3.11 vs. 3.12 or something maybe |
| 10:07 | <annevk> | Bingo, okay, I'll push an updated manifest |
| 10:11 | <annevk> | Though I guess it shouldn't matter since bikeshed-data indeed appears to be source of truth. Hmm. |
| 10:53 | <Kaiido> | Sorry, I doubt I am the right person for fixing color schemes... |
| 13:02 | <TabAtkins> | Bikeshed-data polls bikeshed-boilerplate as part of its update |
| 13:03 | <TabAtkins> | Ah and sorry, you merged the thing that needed coordination while I wasn't around 😃 |
| 15:01 | <annevk> | TabAtkins: I suspect Domenic might be afk for a while, but let me know if there's anything remaining I could help with |
| 15:01 | <TabAtkins> | I'm still not technically around into next Monday but if something needs poking I can fix |
| 15:03 | <annevk> | TabAtkins: I think Domenic was saying that it appears as if api.csswg.org isn't updated |
| 15:03 | <annevk> | TabAtkins: and that's why various specifications are now W3C blue instead of WHATWG green |
| 15:03 | <TabAtkins> | :( |
| 15:06 | <Ms2ger (back in 2024 W2)> | If there's one thing bikeshed should do well, it's painting in the right colour |
| 15:18 | <TabAtkins> | Looks like things are good now, I just did a `make remote` and got whatwg colors |
| 15:19 | <TabAtkins> | So it's just a matter of pinging things to rebuild |
| 15:22 | <annevk> | Thanks TabAtkins. Trying it out with whatwg/dom. |
| 15:24 | <annevk> | And it worked. Hurray. |
| 20:40 | <akaster> | Is there somewhere in the spec where the legacy DOM behavior of `document.myForm` access is mentioned? I know that form elements are supposed to be exposed as named properties on the window (and also globalThis) of the page, but I haven't seen references to that old (Netscape? IE?) Behavior of exposing them on the document as well. |
| 20:42 | <akaster> | Oh I'm just blind |
| 20:42 | <akaster> | It's right below current script on dom.html |
| 20:48 | <akaster> | Named property access on the window, document and forms is just screaming for a cache. The naive "just implement the spec" approach is showing up in profiles on ladybird 🐞 😅 |