[bick_nyers]

I really wanted (and still want) JPEG-XL to succeed.

Not sure how feasible this is, but one thing that could of helped with .jxl is allowing it to be read by a jpeg decoder. Let me explain. JPEG-XL has a feature that allows you to pull out a fully compliant jpeg, if you could somehow send the entire .jxl payload, and the browser's jpeg decoder just decoded the jpeg part, I feel adoption would be significantly easier, because then there is very minimal risk to just serving JPEG-XL with or without browser support.

Edit: Changing jpeg decoders around the world is not the approach I'm suggesting, but rather a carefully done "byte hack". Put the JPEG at the head of the binary blob, and stop decoding when the JPEG ends. If JPEG decoders only stop at the end of the byte stream, then another approach would be required.

[Jasper_]

What value does this provide over serving a .jpg file?

[Kab1r]

Presumably, JPEG-XL decoders would produce higher quality decodes out of the same file while being backwards compatible with browsers that only have support for standard JPEGs

[Jasper_]

If it's backwards-compatible with standard JPEG decompressors, then you've just made a better JPEG encoder. And that's great, and people are still doing that all the time, but we don't need a whole new ISO spec to do it. All of the JPEG-XL enhancements are new additions to the format that aren't backwards-compatible.