2024-01-10 [23:57:45.0177] littledan: I see that https://github.com/tc39/proposal-idl is from 6 years ago. Has there been progress since then in another repo? If not, why did it stall? [09:15:34.0756] hsivonen: Sorry about that. I gathered that people wouldn't want to do another ES6-style set of minor changes all over the semantics of how certain casts work; it was unclear whether this should end up being WebIDL literally or not. Anyway I just didn't put more work into it; someone else could pick it up. [09:15:48.0764] I would be happy to consult with anyone interested in this task [10:02:35.0820] > <@littledan:matrix.org> I would be happy to consult with anyone interested in this task Thanks. At this point, I'm trying to understand why things are the way they are and am not proposing concrete changes. 2024-01-23 [10:41:21.0700] should it be possible to observe the change of system default locale over the course of a single program execution? [10:41:31.0063] I don't see any constraint on deterministic behaviour of https://tc39.es/ecma402/#sec-defaultlocale [10:55:31.0803] > <@michaelficarra:matrix.org> should it be possible to observe the change of system default locale over the course of a single program execution? I don't believe so [10:55:52.0530] ryzokuken: where is that constraint expressed? [10:56:02.0882] right, there are no constraints and the specification text is analogous to that of [SystemTimeZoneIdentifier](https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec-systemtimezoneidentifier). I'd expect most if not all implementations to reflect changes. [10:56:06.0892] I think on the web platform side [10:56:29.0691] There was this PR Frank wax working on to address that [10:56:36.0852] On the whatwg side if I remember correctly [10:56:42.0484] Let me try to find it now [10:56:46.0520] * there are no constraints and the specification text is analogous to that of [SystemTimeZoneIdentifier](https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec-systemtimezoneidentifier). I'd expect most if not all implementations to reflect changes. [10:57:14.0775] * there are no constraints and the specification text is analogous to that of [SystemTimeZoneIdentifier](https://tc39.es/ecma262/multipage/numbers-and-dates.html#sec-systemtimezoneidentifier). I'd expect most if not all implementations to reflect changes (but they should not be required to do so). [10:57:21.0219] Frank was working on an ontimezonechange event. I recall discussion of a onlocalechange event but I'm not sure what came of that [10:57:50.0240] It might not work for locale-change since it is intended to be consistent with the Accept-Language header [10:58:42.0567] > <@sffc:mozilla.org> Frank was working on an ontimezonechange event. I recall discussion of a onlocalechange event but I'm not sure what came of that It was discussed but I don't remember it moving forward, there was something it was blocked on [11:00:13.0331] okay so it sounds like it's not a JS constraint but a web constraint because of that header consistency [12:12:35.0182] HTML has an event for observing the locale change (but I'm not sure if that's plumbed through to being the same as Intl's locale, necessarily). Last I heard, only Firefox ever fired it. [12:12:48.0056] the header, then, only indicates the locale at the time of the request [12:13:25.0006] I think this is a hole we should fill--we should develop a clear model, shared by JS and HTML, of whether the locale can change, and make sure it's noted in both places and appropriate APIs exist (or don't exist) [12:14:06.0853] Mozilla people have raised the importance of live locale changing. We should figure out whether we want that to be part of our shared model *as it relates to the default locale* or whether it should just be an application-level thing.