00:01
<Domenic>
wanderview: https://github.com/whatwg/whatwg.org/issues/253
00:52
<MikeSmith>
TimothyGu: about any of those redirects, you can talk to me. But as far as the HTML51 AND HTML52 TRs, it's intentional that they don't redirect. It's not an oversight. That's how I was specifically asked by W3C to handle those.
00:53
<MikeSmith>
TimothyGu: If you feel strongly that those should be redirected too, lemme know why and I can can try to make a few case to plh
00:58
<TimothyGu>
MikeSmith: ah, didn't know that was intentional. it's fine in that case
01:03
<MikeSmith>
TimothyGu: OK (FWIW, the rationale is those are the published Rec/historical versions)
01:04
<MikeSmith>
there are still a bunch of other redirects I need to set up (e.g., for the WebSocket spec fork)
01:04
<TimothyGu>
MikeSmith: if you're not already aware, there's https://wiki.whatwg.org/wiki/Fork_tracking
01:05
<TimothyGu>
for instance, https://w3c.github.io/dom/ still doesn't redirect yet
01:05
<TimothyGu>
though the TR does
01:15
<MikeSmith>
TimothyGu: oh, OK, yeah, will fix that
05:52
<hsivonen>
TabAtkins: does that mean that Chrome ships a block list of faux friend sets?
08:21
<annevk>
Domenic: I'm reporting these 404 spammers as well btw
09:17
<annevk>
TIL https://en.wikipedia.org/wiki/HTTPRange-14 has its own Wikipedia page
11:42
<MikeSmith>
hsivonen: annevk: https://github.com/validator/validator/issues/874 Can you look and comment about whether the handling of the encoding names (with extra characters) is conforming per spec, or if instead it's.a checker bug
11:43
<annevk>
MikeSmith: that's a valid bug
11:44
<annevk>
MikeSmith: the original HTML spec used the wrong kind of matching for labels and I suspect the validator^Wchecker code hasn't been updated when I changed all that
11:44
<annevk>
MikeSmith: new matching is basically strip whitespace from start and end and then do an ASCII case-insensitive match against all possible enums
11:45
<MikeSmith>
annevk: OK, thanks much
11:48
<MikeSmith>
hmm, I guess this may actually be a bug in the HTML parser. And if so, that means Gecko has the same bug
11:52
<annevk>
MikeSmith: Firefox decodes data:text/html,<meta charset=utf%208>%c2%80 and data:text/html,<meta charset=utf8>%c2%80 quite differently here
12:52
<MikeSmith>
annevk: Ok
13:44
cybai
wonders those update 404.html are sent by spam bots 🤔
13:46
<annevk>
I report them as such
13:46
<cybai>
annevk: ah! I should do that too :D