| 06:54 | <annevk> | Fernando Fiori: I don't think it's working for any repo. I filed https://github.com/specinfra/pr-preview/issues/213 cc Tobie Langel |
| 06:56 | <annevk> | This is currently left to the implementation as it depends on the platform. We have discussed giving more detail about this in the Fetch specification (which partially defines how to go from a URL to a resource), but nobody has done the work. |
| 07:00 | <hsivonen> | annevk: Have you seen https://corp.unicode.org/pipermail/unicode/2026-September/011764.html ? It's a bit annoying how this kind of thing demands attention from folks. Unclear what level of attention should be given. I might have given it too much attention but: https://corp.unicode.org/pipermail/unicode/2026-September/011786.html |
| 07:37 | <annevk> | hsivonen: looking at the spec this just looks like someone had fun with an LLM and then took it too far with registering it? But yeah, hadn't seen this and I don't think I'll care since the IANA encoding registry is a mess anyway. |
| 15:38 | <Tim van der Lippe> | dbaron: Not sure if you are online here atm, but this might be a better place to quicker ask your questions as posted in https://github.com/web-platform-tests/wpt/pull/62624 |
| 15:43 | <Tim van der Lippe> | annevk: Not sure if you saw the ongoing conversation, but I think this test and corresponding HTML PR would need some additional discussion. Since different folks think differently about what to do. Right now, I think Webkit is the only one following the spec hardcoding these values, although it doesn't itself support ActiveText |
| 16:01 | <annevk> | If browsers indeed disagree on the values ActiveText might be an okay solution. It doesn't seem ideal though that we disagree on something so trivial. |
| 16:55 | <emilio> | Tim van der Lippe: where did those dark colors come from? |
| 17:03 | <Dominic Farolino> | annevk: Do you think we're good to land https://github.com/whatwg/html/pull/7617? |
| 17:04 | <Dominic Farolino> | https://lists.webkit.org/pipermail/webkit-dev/2021-December/032067.html doesn't work anymore for the WebKit position. But I assume it's not negative. And positive from Chromium and Firefox meets the bar so we should be set. |
| 17:16 | <dbaron> | Maybe https://lists.webkit.org/archives/list/webkit-dev@lists.webkit.org/thread/IYT4JDXGWZNJEITAOJZAJJZDYQZZVXGT/ is the same message... but it doesn't show any replies. |
| 17:23 | <Luke Warlow> | Fwiw some of this is a chromium on Windows bug. Firefox does seem to just have genuinely different values in dark mode though. The Chromium bug: https://issues.chromium.org/issues/427600164 |
| 17:42 | <myf> | I always thought that system colours (keywords values) were actually supposed to differ across systems, ideally blend with individual personalised OS theme - that this was their primary purpose (?). Sure, having a shared starting "example" values cemented in specs would not spoil anything and help testing, but it feels strange to expect they will be the final ones for every single UA instance in the wild… (Not long ago, |
| 17:52 | <Luke Warlow> | While that's true, the implementation has historically been so broken they've not been useful. LinkText, VisitedText and ActiveText were (and still are sometimes) all the same colour, they also weren't dark mode away. It seems ActiveText still isn't in chromium. |
| 21:14 | <TabAtkins> | I think you spent more effort on that response than the message even deserves, but yes, it's definitely a non-serious proposal that doesn't need to be meaningfully considered. I assume it purely arose from the observation that there are ~21 bits of unicode space, and that happens to fit in 3 7-bit bytes. The fact that it has ASCII-masquerading bytes is a killer just from step 1, unless there's enormous benefits as a counterbalance. |