Comment by F3nd0
3 hours ago
That’s not at all how it went.
Years ago, both Chrome and Firefox had experimental support. In October 2022, Chrome suddenly announced their decision to drop it (citing dubious reasons like lack of interest or improvements over existing formats). [1] It was only later, in January 2023, that Mozilla announced their formal position of not really caring about the format. [2]
In October 2023, one of the JPEG XL devs said that the responsible team at Google was ready to write a decoder in Rust if that was the only reason holding adoption back, even offering to work on browser integration. [3] One month later, another dev confirmed that a different pre-existing decoder written in Rust was already standard-conformant. [4]
It wasn’t until September 2024, nearly a whole year later, that Mozilla changed their official position from not caring to waiting for a suitable decoder written in Rust. [5] And it was only then that jxl-rs development really picked up. [6] Only later on, Chrome decided to change their position as well, but we can only speculate on what actually changed their mind.
There was no Google shoving JPEG XL down everyone’s throat like they once did with WebP. There was no Mozilla taking a clear, principled stance from the get-go. Whether or not JPEG XL was worth it, neither of these companies has acted in a transparently fair, exemplary way. And of course the first major browser to ship JPEG XL support to users was Safari, which may well have played a role in the others’ decision-making.
[1]: https://issues.chromium.org/issues/40168998#comment85
[2]: https://github.com/mozilla/standards-positions/issues/522#issuecomment-1409539985
[3]: https://github.com/web-platform-tests/interop/issues/430#issuecomment-1776762287
[4]: https://github.com/web-platform-tests/interop/issues/430#issuecomment-1811972676
[5]: https://github.com/mozilla/standards-positions/pull/1064
[6]: https://github.com/libjxl/jxl-rs/graphs/contributors?from=03%2F01%2F2024&to=01%2F01%2F2026
All of this reinforces my point, which is that Mozilla is not simply following marching orders handed down by "the Google overlords".
Firefox did not take very long to support AVIF (another recent image format clearly favoured by Google). Please do correct me if I’m wrong, but I’m not aware of Mozilla expressing any reluctance over AVIF’s abysmal lossless performance or other shortcomings (some of which have been addressed since), or insisting on using a memory-safe decoder like they have for JPEG XL. Why the stark difference in treatment?
We may not be able to say for certain, but Google’s massive influence is by far the most plausible explanation I can think of. And if the first step in your decision making is looking at what Google is doing, then ‘following marching orders’ is suddenly not such a bad description. (One can argue that with 3 % market share they don’t have much choice, but that’s beside the point.)
Mozilla was a founding member of the Alliance for Open Media, having sponsored Xiph to create Daala, which was later polymerized with Google's VP10 to create AV1. Mozilla has a vested interested in pushing all things related to AV1, including AVIF. That has nothing to do with Google's favor and everything to do with Mozilla's favor. Their hope was to use the existence of AVIF as leverage to give hardware vendors more incentive to provide hardware support for AV1.
[2] was anticipatory obedience from Mozilla. Good for them that they grew a spine later (or more likely: they knew that Google will implement it some time later, so the change of opinion cost them nothing).
This is mental gymnastics. If Mozilla were following Google's orders we would not need to resort to phrases like "anticipatory obedience" to describe a neutral non-position; if they were following Google's orders, they would have simply endorsed it, end of story, and then they would have revoked that endorsement in lockstep with Google as well, which they didn't.