4 ms·

There is indeed nothing in JPEG-XL worth breaking the entire image ecosystem for, where the image can used in a normal <img> tag, where you can direct link to t

There is indeed nothing in JPEG-XL worth breaking the entire image ecosystem for, where the image can used in a normal <img> tag, where you can direct link to the image URL, where you can save the image, where you can upload the image to any site you want, where you can see the thumbnail in your file browser, where you can open it in any image editor, etc. There is probably never going to be an image format that would be worth throwing all that away for a JS shim that dumps pixels into a <canvas>. But that doesn't mean it is never worth adopting a new format into the image ecosystem.

zamadatix 4y ago
The jxl.js approach actually allows for some of that. Particularly putting <img src="https://jpegxl.info/logo.jxl https://jpegxl.info/logo.jxl"> works like normal (no <canvas>) as jxl.js functions using a mutation observer for such tags which then transcodes the image to a supported format (such as png) and caches it. Similarly you can then save the image in a way you'll have thumbnail support, image editor support, etc - all of course with the downside it'll be e.g. png at that point not the original. One thing that is straight broken is direct linking. Since the transcoding is local the generated cached link is only local relevant. Similarly, since it has to not only spin up a decoder but transcode the image it is impractically slow.