There are very interesting values here.

Somebody could think of the web as primarily a platform for consumption, in which case it is OK for it to support a limited number of formats, actually desirable because it reduces the attack area.

Another is that the web is connected to general purpose computing in which that case the web browser competes with GUI shells (e.g. explorer, finder) and should be able to support every image format that is commonly used on the platform.

Back in the 1990s most platform supported a lot of file formats that weren't JPEG or GIF but browsers didn't support them and only a small set of formats have been added since then.

A long time ago I ran some sites that hosted large image collections and I struggled with costs so I did a lot of thinking about how to optimize storage and transfer. I came to the conclusion about 5 years ago that WebP is consistently a win over Jpeg, but I've never been a fan of AVIF. Yeah, it does great for big blog hero images that people don't look at closely, but it makes my mirrorless shots look like they were shot on a cheap Android. Yeah, I've seen that picture of the F1 car and it is superficially impressive but if you look closely at the highlights you can see that it erased the real highlights and replaced them with something plausible but... different.

And even Firefox took well over a year to bring it up, after stating they didn’t really care for JPEG XL. It was literally no one’s primary concern from the get-go.

“Their own” is a bit misleading. It’s largely a subset of the people who implemented libjxl in the first place, but this time in Rust.

Thanks for pointing that out. The stated reasoning for not supporting JXL is understandable, though quite vague. It feels like the sort of general trade-offs you could cite about not supporting any codec. In my experience in large companies, such 'tough choices' on features that would be "nice to have, but doesn't make the priority cut" are usually driven by demand from internal stakeholders or corp strategy not exceeding budget/head count constraints.

While I'm happy for the reversal, it would be helpful to have a corresponding explanation addressing what changed leading to this reversal just two years later (assuming the decision to support was made 9-12 mos ago). Since significant decisions are usually harder to make in big companies (due to many competing prioritities, stakeholders, and processes), they tend to also be harder to reverse (especially in just two years, when most of original deciders are still in the same roles). I suspect the real thing that changed is more interesting than "the technology or people changed" or "our prior assessment was wrong".

What a silly question, Google has never cared about users.

Yes, I meant Google employees/stakeholders.

They always abandon shit like this.

"Required" is a strong word. More than enough people use Chrome as a PDF viewer that if Google decided to not support JXL, you'd see ~0 PDFs with it.

Another giant codec is only a huge risk if you run the decoder in the renderer process, which they say in the linked thread they do, but I don't see a sane reason why.

I'm sure if they asked the secret Gemini 4.0 AGI to use their existing very good sandbox to throw all the decoders in their own process and only share the image buffers, it could do it in a few hours.

> Removed because having yet another giant C codec was a huge risk

Removed because trillion dollar advertising company don't bother, which also happens to be the browser vendor monopoly.

How many man-hour effort does it take to create jxl-rs ?

https://github.com/libjxl/jxl-rs/graphs/contributors

My favourite tidbit about the Amiga is that it was the first platform that got PNG support in all its web browsers: you just had to install the png.datatype.

If you want things to work every single time on a billion different devices this is how you do it.

  ~$ du -h $(which dd)
  76K     /usr/bin/dd

    $ du -h $(which pv)
    116K     /usr/bin/pv

    sudo pv -Yo /dev/blah /path/to/your/image.img

Indeed. The most goofy is their proprietary Print dialog. I think(?) they added it to gain a previewing pane, but Apple added that capability to the native print dialog about 10 years ago. Chrome still forces its old bespoke one though, and when you do the extra click to get the OS standard one, they apparently don't use the previewing API, so it's missing.

Eh. WebKit, Blink, Gecko being the big ones, supporting Windows, Linux (and alikes — maybe one would consider Android separate in this context) and Darwin (in this context iOS/macOS is the same). Mostly 1:1.

The thing is that it's still just a library, it just happened to be pre-installed. CGImage is just a helper in the Core Graphics library, not some magical "native"/"core" functionality in the OS that would be different than any other library with the same features.

An equivalent library for Linux (glycin for example), or per-format libraries like jxl-rs, are not "included in the OS", and tend to be the very same libraries one would use for Windows. If that does the trick on most platforms, then why have the maintenance burden of doing something different on macOS if all it does is save a few bytes on disk?

From Google's perspective, they would likely not want Chrome for macOS to gain support for jxl as the sole platform anyway, even if they are using CGImage and could decode it that way...

Which both vendor it.