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

What are those new locale APIs?

wipo.int/wipolex your daily Chromeism fail of the day: named capture groups have "captured" the WIPO

now I can't know if I am violating someone's copyright laws :D

it should be UN law that any international organization website should be barred from using JavaScript frame-not-works of any kind!

also this vomit from their framework: "Error: Uncaught (in promise): ChunkLoadError: Loading chunk 775 failed"

...yes, this indeed comes from the regex error

WTF, WIPO also use trackers from Google Analytics and Baidu

That answer is actually wrong and that quotation from the spesification is out of context

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

"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."

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

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.

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

What the specification really says is the opposite

Sompi tc39.es/ecma402/#locale-objects

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.

frg_Away: My forum topic was about the encoding selection menu, not the automatic detection

The original encoding menu is clearly superior to the current one

Sompi yes but even this one need someone to do it and see if it is still possible without changing backend apis.

And the new nerfed encoding menu makes it impossible to view some pages and text files correctly :/

Somehow reading Sivonen's messages makes me angry

Personally this is mostly ancient stuff. If I need these old files I would just download them.

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.

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

And in demoscene it is common

And other DOS codepages also

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 :)

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

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

Sompi I am not against this but it needs to be done and maintained. That is what I don't see.

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.

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

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)

It made no sense to change it in the first place

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

njsg: According to Sivonen's blog writings, that's not why he changed the menu

He just doesn't seem to like it when the user has a choice: hsivonen.fi/encoding-menu

look at the vertical scrollbar here, faststone.org/FSViewerDetail.htm - in FF. it has "markers" (at least on Nightly). not sure what they're supposed to indicate?

oh, that's what it is. it is from Find, & it is displaying a relative location of the found 'word' throughout the page.

therube: so a documentation issue is actually useful just you did not understahd whey the markers were there at first.

WG9s: right.