Browser vendors have other priorities besides having the latest-greatest compressor: code size, attack surface, long-term maintenance and compatibility risks, and interoperability.
Having a format that is a few percent smaller than the formats they already have is just not a high priority.
This isn't a conspiracy against JPEG XL. Browser vendors (other than Google) have been resisting shipping WebP for 10 years, until Chrome-only websites forced them to. GIF still is a thing despite being by far the worst in every image benchmark.
Every few years browser vendors are asked to adopt a new format, which is then beaten by an even newer format, but the vendors are stuck supporting the old one forever. They've dodged the bullet on JPEG 2000 and JPEG XR, but are now stuck with WebP (and AVIF, if they were to replace it).
If in a few years it turns out everyone uses JXL and other vendors have it, Chrome can re-add it.
I think the way to go for browsers is to support new codecs (as long as they're plausibly useful for the web, royalty-free, etc), but to avoid getting stuck with them by having web devs assume they can use codecs without content negotiation / fallbacks. So e.g. they could randomly in 1% of the requests pretend only to support the legacy codec (say jpeg and png for images, or h264 for video), which basically forces web devs to put proper fallbacks in place (using multiple sources, or using http content negotiation) since otherwise random parts of their website would just be broken. Putting those fallbacks in place is needed anyway: it's just a bad practice to ignore the long tail of browsers that don't support the latest codecs yet. The 1% "fallback-only" requests would mainly be a way to force web devs to take that long tail seriously since they would notice the failures even when testing only on Chrome.
That way, we can get 99% of the compression gains of new codecs right now, without having to wait until a codec gets sufficient traction outside the web, and without getting stuck with the codec forever if it turns out not to be that great after all, or if a better alternative shows up. If it does turn out to be great and it gets ubiquitous support everywhere (like JPEG and PNG), then it can be considered to make it a permanent addition to the web platform, i.e. make it part of the "fallback formats" pool instead of the "99% of the requests" pool.
The web platform needs a long-term media codec deprecation strategy. It needs to be a better strategy than just resisting any change until a codec has become ubiquitous and unavoidable — the web is an extremely important use case for media compression, and it's at this point unlikely that new codecs can even become ubiquitous when they cannot be used for this key use case. I think the strategy of "enable by default but only for 99% of requests", as bizarre as it may seem at first glance, would be a good way to make progress without adding irreversible bloat to the web platform at every step.
For Web APIs there are various motivations. For example, the Chrome side of Google sees native apps as an existential threat, so parity with native trumps most other concerns (IMHO they're exaggerating, but that's what they do). In terms of images they aren't behind enough to worry: AVIF is close enough to HEIC (both are based on the HEIF spec).
Incremental upgrades to CSS properties and selectors may take less code than an advanced codec library, and it's 1st party code, not 3rd party code. There's likely an engineering bias here: everyone prefers to write their own code and trusts it more. Dependencies are automatically seen as suspicious.
Some new flashy APIs like VR/AR, local filesystem access, WebAuthn, or payment request enable functionality that was not possible before. That's user-visible and adds something to the platform. On a high level a new codec is just images, like the platform already had, only a little bit faster. I advocate for web performance, but I also realize it's a tough sell, not a "wow" feature that can be used in marketing. Most sites aren't even optimizing their JPEGs yet, WebP has very little use, almost nobody uses AVIF, so lack of a better codec isn't a limiting factor yet for web perf in general.
In terms of "fire and motion" play, they can churn 400 minor CSS or JS properties to get 400 points in browser-vs-browser comparisons. JPEG XL just gives them one checkbox. Even looking at this super cynically, if they add a WebTrombone API that no other vendor wants, they'll get to permanently look better in "who's got more APIs" comparisons, but JPEG XL can be easily added to other engines. However, if you convince other vendors to release JPEG XL support, and add it to high-profile benchmarks, Google may be more interested.
HEIC and AVIF are similar, similar like a Barbie toy and a monster truck toy placed in a similarly sized box, wrapped in the same Christmas wrapping, both with a red rosette clued on the box. Toy connoisseurs focus on what is inside.
>Browser vendors have other priorities besides having the latest-greatest compressor: code size, attack surface, long-term maintenance and compatibility risks, and interoperability.
You’ve missed two most important ones: “business reasons”, eg trying to harm some (potential) competitor, and someone trying to get promoted. Don’t assume there are valid technical reasons behind every corporate decision like those; usually there aren’t.
Maybe if JPEG XL had a chat functionality, Google would have a motivation to include it…
But seriously, it's an ISO standard with a free implementation. There's no Google competitor attached to it. Nobody gets prompted for failing to add features. Google is even missing out on a chance to make Safari look outdated again. There's no reason to interpret indifference as a conspiracy.
BTW: I've worked on the HTML5 spec and codecs for many years, so I've seen how the sausage is made on both sides.
Incorrect. Facebook have said they want to use JPEG-XL. Facebook/instagram is definitely a big tech competitor to google, especially in regards to ads.
Having a format that is a few percent smaller than the formats they already have is just not a high priority.
This isn't a conspiracy against JPEG XL. Browser vendors (other than Google) have been resisting shipping WebP for 10 years, until Chrome-only websites forced them to. GIF still is a thing despite being by far the worst in every image benchmark.
Every few years browser vendors are asked to adopt a new format, which is then beaten by an even newer format, but the vendors are stuck supporting the old one forever. They've dodged the bullet on JPEG 2000 and JPEG XR, but are now stuck with WebP (and AVIF, if they were to replace it).
If in a few years it turns out everyone uses JXL and other vendors have it, Chrome can re-add it.