WHATWG on 2024-09-20

01:24	<Domenic>	Kind of an interesting case... we're considering registering a URL that serves as an identifier, for a WICG spec. It would be unfortunate if that URL was `https://wicg.github.io/blah` since WICG is supposed to be a temporary home. I wonder if it'd make sense to allocate a `https://whatwg.org/` URL before WICG graduation? The alternative we're considering is to just use an `about:` URL. https://github.com/WICG/nav-speculation/issues/330#issuecomment-2357573086
04:55	<annevk>	Domenic: it seems you could just follow precedent in https://www.iana.org/assignments/http-problem-types/http-problem-types.xhtml and have it prefixed with the IANA URL?
04:56	<Domenic>	Hmm I suppose so. And I guess then we can update the reference column over time. So it's almost as good as a normal URL, just requires the developer to do an extra click to reach the spec.
04:57	<annevk>	hsivonen: I think so, though I think of GBK more as the two-byte mappings of GB18030-2022 + a couple minor encoder changes.
05:33	<annevk>	zcorpan: can "update the source set" run again when the environment changes in some way?
05:57	<zcorpan>	zcorpan: can "update the source set" run again when the environment changes in some way? https://html.spec.whatwg.org/multipage/images.html#reacting-to-environment-changes
06:09	<annevk>	Oh, maximum leeway. Seems dangerous. Are you going to attend TPAC zcorpan?
06:15	<annevk>	hsivonen: I was clicking around yesterday because what else should one do and I found https://github.com/whatwg/encoding/commit/e7b9ce0ed75da6bbc87aa952194025a03df97ce6. Which means that index gb18030 ranges does not reflect GB18030-2005, it reflects GB18030-2000. And the pointer algorithms make it match GB18030-2005! It also means that back then we didn't do the equivalent of the Unicode recommendation for 2022.
06:19	<annevk>	I'm half-tempted to implement the equivalent of the Unicode recommendation for 2022 for 2005, but only half and I will resist as it's been stable for so long and none of these changes should have been made to begin with. I will further correct the index gb18030 ranges wording though.
07:42	<zcorpan>	annevk: I will attend TPAC yes. There was no hook for environment changes and I wanted to allow not running the steps when the tab is in the background for example. Though I didn't intend for it to be "may at any time" forever.
10:13	<hsivonen>	hsivonen: I was clicking around yesterday because what else should one do and I found https://github.com/whatwg/encoding/commit/e7b9ce0ed75da6bbc87aa952194025a03df97ce6. Which means that index gb18030 ranges does not reflect GB18030-2005, it reflects GB18030-2000. And the pointer algorithms make it match GB18030-2005! It also means that back then we didn't do the equivalent of the Unicode recommendation for 2022. Thanks for looking into this. Was U+1E3F really the only change from -2000 to -2005? Now I feel I need to investigate how U+E7C7 behaves to see if the number of unrepresentable PUA code points is now 20 instead of 19. I still find it mysterious that there are PUA mappings with established glyphs left, such as 0xFE, 0x52. Why didn't -2022 map those to relevant non-PUA?
10:20	<hsivonen>	Thanks for looking into this. Was U+1E3F really the only change from -2000 to -2005? Now I feel I need to investigate how U+E7C7 behaves to see if the number of unrepresentable PUA code points is now 20 instead of 19. I still find it mysterious that there are PUA mappings with established glyphs left, such as 0xFE, 0x52. Why didn't -2022 map those to relevant non-PUA? Ah, we do have a four-byte sequence for U+E7C7.
10:21	<hsivonen>	Ah, we do have a four-byte sequence for U+E7C7. (I even have specific tests for it in encoding_rs.)
11:12	<annevk>	hsivonen: indeed, https://encoding.spec.whatwg.org/#index-gb18030-ranges-code-point handles it specifically. I updated the PR to have an even more elaborate explanation for index gb18030 ranges.
11:14	<hsivonen>	hsivonen: indeed, https://encoding.spec.whatwg.org/#index-gb18030-ranges-code-point handles it specifically. I updated the PR to have an even more elaborate explanation for index gb18030 ranges. So that change got different backwards-compatibility treatment than the -2022 changes, right? (Not suggesting any change here. Just trying to understand all the moving parts.)
11:36	<annevk>	hsivonen: indeed. That change we handled exactly as the authors of 2005 wanted (and also as the authors of 2022 envisioned, but Unicode then overrode successfully somehow).
11:38	<hsivonen>	hsivonen: indeed. That change we handled exactly as the authors of 2005 wanted (and also as the authors of 2022 envisioned, but Unicode then overrode successfully somehow). OK. (Not worthwhile trying to retroactively align the 2005 change approach with the 2022 change approach.)
14:29	<annevk>	TabAtkins: should be easy r+: https://github.com/speced/bikeshed/pull/2925
14:32	<Ms2ger>	nl is a fake language
14:52	<annevk>	Ms2ger: je ne sais quoi
14:52	<annevk>	TabAtkins: hah, too easy. So how do I bump semver? I looked around a bit, but nothing jumped out to me.
15:02	<annevk>	Hmm, I think I managed to hack something together by commenting out some stuff in release.py
15:04	<TabAtkins>	No need, that's picked up by bikeshed-data
15:06	<annevk>	TabAtkins: interesting. I guess I'll try again then and see. Also, https://github.com/speced/bikeshed/pull/2926 created a diff I can't quite explain but I guess that can be closed then.
15:17	<TabAtkins>	Yeah it just takes a few minutes for the data update to cron https://github.com/speced/bikeshed-data/commit/d64bb355d04f7824190b929191964f8d9c5214d7
15:18	<TabAtkins>	`bikeshed update` will pick it up now