Is there are any data to back up the claim that "the benefits it provides are not significant enough"?

What % compression gain over already-supported codecs is considered "significant enough"? Currently the best available data suggests that the gain jxl offers over existing codecs like avif is about 17%. Is it the official position of Mozilla that 17% reduction in bandwidth for images is insignificant, or does Mozilla dispute the available data?

What makes new features (like lossless jpeg recompression, new kinds of progressive loading, etc) significant or not significant? Is there any argumentation provided by Mozilla to argue the position that none of the advantages of JPEG XL are significant?

It would be very interesting to get more detailed information on the rationale and data underlying this position. I assume such data/argumentation is readily available and that Mozilla didn't come to a position on a controversial topic like this lightly. In the spirit of transparency, it would be good to make the data and argumentation available, and not just the conclusion.

What I'm confused about here is that Firefox already has support for this format behind a flag (code is in https://searchfox.org/mozilla-central/source/media/libjxl).

In nightly builds, you just need to turn on the image.jxl.enabled preference in about:config . Reload https://jpegxl.info/ to check that support works.

What I'm confused about here is that Firefox already has support for this format behind a flag

A position isn't determined by whether there's code in Firefox (and vice versa). This is addressed by https://github.com/mozilla/standards-positions#what-about-firefox:

A position here does not address whether Mozilla will commit resources to developing a specification. In particular, taking a position does not commit Mozilla to implementing a specification in Firefox.

A position isn't determined by whether there's code in Firefox (and vice versa). This is addressed by https://github.com/mozilla/standards-positions#what-about-firefox:

A position here does not address whether Mozilla will commit resources to developing a specification. In particular, taking a position does not commit Mozilla to implementing a specification in Firefox.

Sorry, but here Mozilla did the work to integrate that code - resources were committed already since Mozilla employees both worked on the patches to integrate a third party library and to review that integration.

It looks a bit like an after the fact decision, which can be fine, you can change your mind.

@jonsneyers, our assessment is not based on our own testing, but from your own results and the results published by others. We don't make these assessments lightly, but nor are we able to dedicate as much time to each request as would be ideal.

@fabricedesre, as @bgrins explained, the code we have is not relevant to the position we take. Also, that implementation isn't quite ready for wider deployment and we haven't estimated how much more effort it would take to finish it.

What would need to change in JPEG XL for Mozilla to re-evaluate your position?

Would we need more compression efficiency in the encoder? Less memory use? More speed? More robustness for difficult cases? Smaller decoder binary size?

Would an increase in non-web adoption change Mozilla's position? Would it be any different for Mozilla when the industrial verification, medical image compression, photography community or the AI world would center themselves around JPEG XL for its favorable properties there?

Why the hell Mozilla doesn't want to include more formats? Why do you follow Google every goddamn step? Why do we need Firefox if we can have the SAME stuff in Chrome?