hsivonen

Already done: https://farre.github.io/midas/

Hare is presented with the expectation that it would be included in Linux distros. With that framing, criticism on matters that are relevant to distro-included software is indeed relevant.

Your example is not an example of actual Firefox failure mode: If I encode your text as ISO-8859-1 and run chardetng on the bytes, it says ISO-8859-2. It’s generally unlikely that chardetng would misdetect ISO-8859-2 Polish as windows-1252.

When you claim that something isn’t working for you (and it’s completely plausible that you have encountered a case where chardetng doesn’t work for you), it would be polite to post the actual failure and not something that’s not an actual example of failure.

Have you encountered concrete cases of failures with Cyrillic single-byte encodings (where the letters fail; there are cases where box drawing characters fail due to preferring letters over box drawing)?

The reason why this seems easy while the built-in feature got in the way of other changes is that the built-in feature dealt with more issues. For example: https://hsivonen.com/test/moz/never-show-user-supplied-conte...

Please do not remove working features, especially if they have no effect on security or privacy.

As it happens, part of what made the menu back end cause other changes to take more effort than they should have taken on their face were the security aspects of the menu in Firefox.

Try https://hsivonen.com/test/moz/never-show-user-supplied-conte... in Firefox 90 (which had the menu) and in another browser that has a menu or an extension that adds a menu.

As a matter of usage and severity of failure mode, East Asian languages are very much the main concern. Japanese specifically is the primary motivator for keeping the feature in any form.

If there's more elaborate UI surface in order to address Latin-script cases where autodetection fails (I estimate 1% failure rate for Polish), it risks getting the whole thing removed completely even for Japanese users (as happened with the hamburger menu entry point in Firefox when the hamburger menu was rewritten, as happened in Chrome previously, and as happened with Safari for iOS in the sense of the menu never making it to iOS).

Basically, when you need to read some very old Japanese site where their encoding is pretty non standard, you are screwed.

As it happens, the primary reason why the single menu item remains instead of an override being totally gone is usage in Japan. (Many people in this thread comment as if Firefox had done what Chrome did: complete removal of override as you note.) The remaining menu item is pretty accurate for its primary use case, which is dealing with Japanese legacy sites that misdeclare their encoding. (There is one exception: If the page declares UTF-8 but is actually ISO-2022-JP, then you don't have recourse.)

After the submenu was replaced with a single item in August, how many times have you 1) encountered Polish mojibake and 2) the single item wasn't able to fix it?

In cases where Chrome autodetects, Firefox autodetects, too.

In the cases where you'd use the remaining menu item in Firefox, Chrome offers no recourse (apart from extensions).

A complicating factor on the telemetry is that both this new "guess" option and its predecessor list are/were in the menubar View menu and have no way to be accessed through the "hamburger," so there wasn't a default-visible way to get to this functionality for Windows and Linux users.

The collapsing the submenu of the View menu into a single item shipped in Firefox 91. The submenu was removed from the hamburger menu in Firefox 89.

This order of changes was unfortunate. If I had gotten the single-item design done sooner, perhaps the rewritten hamburger menu would have kept the single item instead of removing the entry point altogether.

Notably, the single menu item in Firefox does what it says on this page, so this page doesn't demonstrate why having just one menu item is a problem.

Speaking as someone whose native language is non-Latin-based, I think it was a very bad idea.

Bad in principle or bad because you've personally encountered pages where the menu item doesn't work but macOS Safari's submenu does?

https://hsivonen.fi/utf-8-detection/ explains why Firefox doesn’t.

The crate linked to from the comment you replied to uses RUSTC_BOOTSTRAP for a non-SIMD reason: To allow Firefox to be built with somewhat old rustc.

Firefox no longer updates its MSRV in sync with Rust release trains. I’d be happy to remove this particular RUSTC_BOOTSTRAP if we decided to increase Firefox’s MSRV (currently stuck at 1.47.0).

IE defaults to the locale-dependent legacy Windows code page.

Why can't we assume UTF-8 unless told otherwise?

See https://hsivonen.fi/utf-8-detection/

in the case of offline where there are no http headers, the browser works out what encoding to use

For file: URLs, Firefox and, a bit less reliably, Chrome do work out that an HTML file is UTF-8. Safari does not.

And since utf-8 is the only valid charset for HTML5

Correct.

it should be the default.

It isn't. See https://hsivonen.fi/utf-8-detection/ for why.

Having <meta charset="UTF-8"> in the boilerplate is good advice.

“And that they do this on regular occasions.”

This is news to me. I thought the main advantage of iTunes compared to other services was that purchases would last as long as the iTunes service is operational and that iTunes has outlived “purchase with DRM” services so far. Are there concrete examples?

What’s your use case for UTF-32?

Does there exist a use case in portable code such that use of isdigit is not a bug?

How does the committee view non-portable existing code generally when considering changes?

What’s the current committee thinking on providing locale-independent conversions from potentially-invalid UTF-8 to valid UTF-8, from potentially-invalid UTF-8 to valid UTF-16, and from potentially-invalid UTF-16 to valid UTF-8 (i.e. replacing ill-formed sequences with yhe REPLACEMENT CHARACTER)?

Does the committee have any plans to document the rationale for each kind of Undefined Behavior?

Does the committee have any plans to make NULL pointer arguments to memcpy non-UB when the size argument is 0?

In practice not. In theory, it’s implementation-defined whether yhere are differences.

Does the committee have plans to deprecate (as in: give compiler license to complain suchthat compiler developers can appeal to yhe standard when users complain back) locale-sensitive functions like isdigit, which is useless for processing protocol syntax, because it is locale-sensitive, and useless for processing natural-language text, because it examines only one UTF-8 codw unit?

K does not belong together with C and J in this case. If you are subsetting fonts to include the actually-used glyphs, the font file size for a typical Korean-language site will be considerably smaller than for a typical Chinese-language or Japanese-language site. That is, the active set of glyphs for Korean is much smaller even if the fonts you’d start the subsetting process from were about as large.

Self-hosting a Japanese font for one line of text is completely doable. I self-host all fonts for my site, which has a handful of CJK characters (across 4 fonts: Korean, Japanese, Traditional Chinese, and Simplified Chinese).

That was more South Korea’s own bad crypto policy’s fault than Microsoft’s fault, though.

My main hope for flang is that it motivates LLVM to fix the Rust-relevant non-aliasing bugs. However, is it actually known that flang/f18 emits IR with the same patterns that exposed the Rust-relevant LLVM bugs?

Is there a catch?

No rr/Pernosco.

You can add Kotlin to you app without rewriting all Java. You can add TypeScript to your app without rewriting all JavaScript. You can add Rust to your app with with rewriting all C++. Seems reasonable.

That Python 2 and 3 can't co-exist in an app is pretty bad in comparison.