Wasn't it due to poor security? libjxl had notorious bugs that would've on par with webp exploit, if present in browser:

https://security.snyk.io/vuln/?search=libjxl

I remember Project Zero cautioning Google's browser team against adding insecure decoders/encoders.

▲

erk__ 3 hours ago | parent | next [-]

No, that was not part of the reason the Google Chrome team gave: https://groups.google.com/a/chromium.org/g/blink-dev/c/WjCKc...

▲

PaulHoule 2 hours ago | parent [-]

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.

▲

asadotzler an hour ago | parent | next [-]

We had plug-ins to support them all.

	▲	mort96 37 minutes ago \| parent [-]
		And that was a pretty bad solution. Nobody wants to see "this web page doesn't display correctly because you're missing the bla bla plug-in".

▲

dist-epoch an hour ago | parent | prev [-]

Interesting.

I'm on the other side, I hate webp because if I download such an image a lot of apps don't support it. So typically I need to screenshot it instead to get a usable jpg/png.

Now one more format to hate.

I would say webp/jxl/avif is anti-general compute, since they require very recent software.

	▲	mort96 36 minutes ago \| parent [-]
		Some people get mad at this reason for hating WebP, but it's so true. The main way in which most people's lives are affected by WebP is that images they download from the web no longer work.

▲

j16sdiz 2 hours ago | parent | prev | next [-]

that's what firefox said, not chrome

▲

dncornholio 4 hours ago | parent | prev [-]

Probably why Google implemented their own decoder in Rust

https://developer.chrome.com/blog/jpeg-xl-in-chrome#safety_f...

▲

mrandish 13 minutes ago | parent | next [-]

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

▲

spider-mario 3 hours ago | parent | prev [-]

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

▲

paimapi 2 hours ago | parent | next [-]

I'm sure those implementers got their fair share of the Google profit or at least a nominal donation for doing most of the work of building out a feature enhancement

right?

▲

lern_too_spel 2 hours ago | parent | prev [-]

The top three contributors to the reference implementation are also Google employees. https://github.com/libjxl/libjxl/graphs/contributors?all=1

	▲	spider-mario 2 hours ago \| parent [-]
		That’s what I was getting at, yes. (I contributed to both and am sitting with another core contributor right now.)