It doesn't matter too much (for the web) as you can use <picture> and <source> and specify multiple jxl/avif/webp/jpeg sources, and the browser will choose the first type it understands. These elements are widely supported.

Hopefully JXL doesn't become yet another image format (927)... some features of it are incredible. For example, you can have mixed lossless/lossy content in one image. No longer will you need to choose between a lossy or lossless format: the encoder would intelligently segment the image.

> you can have mixed lossless/lossy content in one image. No longer will you need to choose between a lossy or lossless format: the encoder would intelligently segment the image.

What's the advantage of that? If I'm dissatisfied with the compression quality in some areas, I can tweak the quality parameter already.

See https://github.com/libjxl/libjxl/pull/466 for more details.

As far as I understand it, the synthetic mode compresses better for (as you can guess) synthetic content. So if you're encoding a mixed content screenshot, you'll get better quality and size by encoding the photos and UI separately.

Oh I see, that makes sense.

I'm surprised that there seem to be no polyfills.

Polyfills for image and video formats are pretty much never going to be worth it: they’ll be a fairly hefty chunk of code (so you’ll need a lot of shrunk-by-using-the-polyfilled-format images to balance it out), and they’ll load much more slowly than the native (so that lot of images is now a liability), while not being able to smooth loading the way stuff native to the browser does. I don’t think a compelling reason to do it that way has ever or is ever likely to exist; it’s an all-round bad idea in practice. Just fall back to a different format, that’s what <picture> is designed for.

I'm not sure how big a jxl decoder has to be, but there's a wasm webp decoder that zips to about 50KB. That kind of cost pays for itself very quickly.

And whether it loads faster or slower depends on your connection. But yes it hurts to not get the smoothness benefits.

Hmm… https://webmproject.github.io/libwebp-demo/webp_wasm/index.h... ships 141KB/54KB (bytes/transferred) of WASM and 116KB/34KB of JavaScript, including lots of bogus SDL stuff. https://kenchris.github.io/wasm-webp/ is 120KB/44KB of WASM and 30KB/9KB of JavaScript, much more reasonable. (Incidentally, I never like the JavaScript such tools produce; it’s always hideously unoptimised. Experience suggests to me that I could reduce that 30KB to under 10KB with a little effort, and possibly to under 5KB; and if I could touch the WASM as well, still further.)

Definitely smaller than I thought I recalled, and WASM bytes are no dearer than image bytes, though JS bytes are much more expensive, so it’s closer to just the more expensive decoding of the actual images that’ll bite you. Plus the not-integrated loading experience, of course.