00:00:56 Browsers used to prioritize the html meta charset over the charset in the content-type field of the http response. Then the mainstream browsers changed it the other way around for some reason and now it is impossible to change the charset of a site if the maintainer of the site doesn't also own the server where the site is hosted 00:01:23 What are those new locale APIs? 00:05:13 https://www.wipo.int/wipolex/ your daily Chromeism fail of the day: named capture groups have "captured" the WIPO 00:05:30 now I can't know if I am violating someone's copyright laws :D 00:06:15 it should be UN law that any international organization website should be barred from using JavaScript frame-not-works of any kind! 00:06:46 also this vomit from their framework: "Error: Uncaught (in promise): ChunkLoadError: Loading chunk 775 failed" 00:07:19 ...yes, this indeed comes from the regex error 00:08:06 WTF, WIPO also use trackers from Google Analytics and Baidu 00:10:29 https://stackoverflow.com/questions/5436452/detecting-character-encoding-in-html 00:11:10 That answer is actually wrong and that quotation from the spesification is out of context 00:12:35 By reading the whole chapter "5.2.2 Specifying the character encoding" it can be noticed that actually that prioritization is only for parsing and not for how the actual rendered page is shown to the user 00:13:31 "To address server or configuration limitations, HTML documents may include explicit information about the document's character encoding; the META element can be used to provide user agents with this information." 00:18:55 Often having the charset specified in the Content-type field of the HTTP response is harmful, because the server has no way of knowing the actual character set of a text file 10:02:55 Sompi: I recall a long time ago being told or reading that, when the server one is present, the http-equiv one should be ignored, or: that the http-equiv one was for when the server did not serve one. Not saying it's one way or the other, just saying I remember something along these lines. 10:08:11 njsg: For some reason it seems to be how the specification is often interpreted, but it seems to be based on that out-of-context quotation of it 10:08:29 What the specification really says is the opposite 11:35:11 Sompi https://tc39.es/ecma402/#locale-objects 11:37:01 text encoding and decoding is/was under heavy development in Gecko. We are keeping SeaMonkey afloat but are not core developers. I don't see anyone modifing the internals to change character detection or encoding any time soon. 11:38:36 frg_Away: My forum topic was about the encoding selection menu, not the automatic detection 11:38:57 The original encoding menu is clearly superior to the current one 11:39:26 Sompi yes but even this one need someone to do it and see if it is still possible without changing backend apis. 11:39:48 And the new nerfed encoding menu makes it impossible to view some pages and text files correctly :/ 11:40:48 https://bugzilla.mozilla.org/show_bug.cgi?id=1036837 11:41:11 Somehow reading Sivonen's messages makes me angry 11:43:20 Personally this is mostly ancient stuff. If I need these old files I would just download them. 11:43:50 frg_Away: And yes, I understand that it is a lot of work to revert back to the old encoding menu. That's exactly why I don't understand why it was changed in the first place. 11:45:01 Changing it broke so much stuff. Some people browse that "ancient" stuff on daily basis, and not all text files in IBM850 are ancient. FreeDOS users often save files in such charsets 11:45:18 And in demoscene it is common 11:45:33 And other DOS codepages also 11:47:15 Sompi well my usual stance is that a browser is not a museum. And these are ancient encodings. Makes sense to clean up now and then. Personally I have more use for codepage 1047 than 850 these days :) 11:51:42 frg_Away: If you don't use it, it doesn't mean that no-one else uses. Almost all encodings are "ancient" but they are still being used. DOS encodings are still being used and there is a lot of web pages and files out there using them 11:52:31 That "not a museum" argument is only good for making people angry. The fact is that the browser used to be able to show those pages correctly, and after nerfing the encoding menu it isn't anymore 11:52:53 Sompi I am not against this but it needs to be done and maintained. That is what I don't see. 11:54:19 Sompi If I need to run old stuff I usually fire up a vm with old versions. I dislike the standard of the day and everchanging current web but now and then cleanups need to happen. 11:54:23 I understand that, and that's exactly why I don't understand why the menu was changed in the first place. Must have been a lot of work to do that, instead of just letting it be and not fixing something that isn't broken 11:55:06 But this is about character encodings. A browser must support multiple character encodings anyway, so why not have a proper encoding menu with an option to add and remove encodings (like it used to be) 11:55:22 It made no sense to change it in the first place 11:55:52 Sompi: re: "lot of work", could be the other way around: if the code for the new locale API required code changes that broke the menu, and the correspoding firefox code had the new menu 11:56:18 njsg: According to Sivonen's blog writings, that's not why he changed the menu 11:57:47 He just doesn't seem to like it when the user has a choice: https://hsivonen.fi/encoding-menu/ 16:35:42 look at the vertical scrollbar here, https://www.faststone.org/FSViewerDetail.htm - in FF. it has "markers" (at least on Nightly). not sure what they're supposed to indicate? 16:36:37 oh, that's what it is. it is from Find, & it is displaying a relative location of the found 'word' throughout the page. 18:21:47 therube: so a documentation issue is actually useful just you did not understahd whey the markers were there at first. 18:22:09 WG9s: right.