Their justification was more that adding it would be committing a lot of hardware and software vendors to support it which would be very expensive for not enough gain.
More accurately, their justification was based on discredited benchmarks (which used a fairly old-even-at-the-time version of libjxl and IIRC created by the AVIF team)... and the commit to remove support was created by a co-author of WebP who gives talks on WebP and is the primary contributor to libwebp.
The Chromium issue where they made this decision is full of "hardware and software vendors" (Adobe, Serif/Affinity, Krita, Facebook, Shopify, Cloudinary, Intel, Nvidia, the VESA DisplayHDR Chairman) telling them they're making a terrible decision and is one of the most-starred and most-commented-on issues of all time for Chromium.
You certainly have an opinion, but you do also keep leaving out facts that don't particularly support it, both here, and elsewhere.
"and the commit to remove support was created by a co-author of WebP who gives talks on WebP and is the primary contributor to libwebp."
Google also employs two of the co-authors of JPEG XL, who give talks on JPEG XL, and was were two of the primary contributors to libjxl.
The main authors of the JPEG XL specification are Jyrki Alakuijala, Jon Sneyers, and Luca Versari. Jyrki is a Googler. Jon is at Cloudinary. Luca is also at Google.
If you are going to try to come up with a silly conspiracy about this being WebP related, it probably would help if this wasn't the case.
Maybe consider that they do in fact have the expertise necessary to decide whether JPEG-XL is something they want to do?
I mean, seriously. You can disagree with the decision, but your argument that they have no idea what they are doing WRT to JPEG-XL seems pretty silly - the only company who arguably has any better idea would be cloudinary.
Phrasing this like "well Google must know best because they employ some subset of the people that worked on JXL" when the entire rest of the industry has been very overwhelmingly pro-JXL isn't very convincing.
Also my point wasn't "Google doesn't know what they're doing", it's that internal politics at Google are probably a factor in them basically being the only opposition to a standard that has been gaining support significantly faster than WebP or AVIF (both much older formats at this point) ever did.
»they do in fact have the expertise necessary to decide whether JPEG-XL is something they want to do?«
The problem is that they do have the people with expertise but those were not asked. For example, the AVIF team at Google does not have the expertise — they have proven that publicly (there was a AVIF vs JXL comparison thing that got put out) and later on an response they gave to Sneyers (the response got shared on Discord).
Hardware accelerated handling was one of the arguments used to oppose a WASM based implementation that sites could use at will to prove that there's demand for JPEG-XL support (and that the Chrome team provides, by the way).
No it wasn't. WASM implementations are simply slower than native support. No browser uses HW accelerated decode for AVIF images or JXL. I think Safari might use HW for JPEG, but that's it across all browsers.
Firefox came to the conclusion they didn't really care too so it's not just Google that is iffy about it. With Apple pushing it now... maybe that will change things in the long run?
Firefox has next to zero marketshare (unfortunately and despite my best efforts to get people to use FF). There was never any chance that Mozilla was going to waste their very limited resources attempting to be the early adopters of an image codec when nobody is going to use it on the web until the browser engine with de facto control over the market starts supporting it.
>never any chance that Mozilla was going to waste their very limited resources
Mozilla is many things, but "limited resources" Mozilla is not.
That is if they would stop paying their CEO their entire coffer, anyway.
>be the early adopters of an image codec when nobody is going to use it on the web until the browser engine with de facto control over the market starts supporting it.
The exact opposite mentality was how Firefox and then Chrome usurped the throne from Internet Explorer. Firefox is never going to usurp anything again so long as Mozilla is content to play second and third fiddle.
AFAIK (correct me if I’m wrong!) first-party and third-party codecs in media players are kinda equal: you load a file, and the media player picks which codec to delegate that file to. You can’t do that in with a Chrome extension – the extensions can manipulate HTML and run custom JS, but that’s more or less it (plus some basic browser-level stuff like work with tabs and intercept network requests).
This doesn’t mean an extension isn’t possible at all – eg there’s https://github.com/zamfofex/jxl-crx/ that detects JXL images and decodes them with JS – but that’s slower.
Plus the bigger issue is adoption. You want all users to get your JPEG XL images, not just the 0.1% of users that installed the extension.
WebP isn't good enough. AVIF isn't good enough. JPEG XL is good enough.