Sad day for image formats. JXL really looked like the future, it could have replaced all the image formats I use on my websites. Especially the lossless JPEG recompression mode, for which there is no existing option.
I think I will continue using it with WASM polyfills, in hopes that Google will change their mind once the rest of the industry has switched to JXL.
> I think I will continue using it with WASM polyfills
This is the answer. You can also build your own application-specific codecs this way.
I've been exploring a variation of jpeg/mpeg that uses arithmetic coding and larger block sizes. Virtually all of the fun patented stuff we couldn't use in the early 00's is in the public domain now.
One of the main benefits of JPEG XL is a superior progressive decoding and polyfills won't be never able to replicate that feature.
Why do you think that polyfills can't implement progressive decoding?
It's simply a matter of using for progressive rendering.
Canvas has to retain all pixels unconditionally, unlike native images that can be unloaded from memory as needed. It is technically possible to implement all other features (using service workers or CSS Houdini), but tons of limitations apply and can easily outstrip supposed benefits.
Can't you just read the stream and emit the images(s) as they get downloaded to be rendered in a canvas - exactly as a native implementation would do?
- Rendering images from a different origin without CORS. This is a fundamental limitation of any JS or WebAssembly solution and can't be fixed. Thankfully this use case is relatively rare.
- Not all approaches can provide a seamless upgrade. For example if you replace all `` with a canvas DOM will be changed and anything expecting the element to be HTMLImageElement will break. Likewise, CSS Painting API [1] (a relevant part of CSS Houdini) requires you to explicitly write `paint(foo)` everywhere. The only seamless solution will be therefore a service worker, but it can't introduce any new image format; it can only convert to natively supported formats. And browsers currently don't have a "raw" image format for this purpose. JXL.js [2] for example had to use JPEG as a delivery format because other formats were too slow, as I've been told.
- It is very hard to check if a certain image is visible or not, and react accordingly. This is what I intended to imply by saying that canvas has to unconditionally retain all pixels, because if implementations can't decide if it's safe to unload images, they can't do so and memory will contain invisible images in the form of canvases. Browsers do have a ground truth and so can safely unload currently invisible images from memory when the memory pressure is high.
[1] https://developer.mozilla.org/en-US/docs/Web/API/CSS_Paintin...