I think the decision on JPEG XL as a whole is made; there were some statements in favor of adopting it on Chrome's and Mozilla's trackers before the decision fr

I think the decision on JPEG XL as a whole is made; there were some statements in favor of adopting it on Chrome's and Mozilla's trackers before the decision from folks at Adobe, Facebook, Intel, and a newspaper, and some developers of it and natural advocates of it were inside Google; general-public comments seem less impactful than all that. If I had to guess, the trigger was Apple supporting AVIF and Chrome folks concluding AVIF "won." They might also have decided they think Apple is unlikely to ever do JXL, but they probably wouldn't comment publicly on what they think someone else will do. The case for a Brunsli filter in the meantime is legacy JPEG content is never going away, and there will also be a long "meantime" where we know AVIF is the endpoint but it's still impractical for many because of SW encoding cost. Brunsli saves ~20%, so it's not nothing, and it's CPU-cheap. A WASM polyfill would kind of be cool. Someone did it for Bellard's "BPG" (HEIC in a different container) in a ServiceWorker, and one just doing JPEG1 transcoding would be even lighter (and, unlike this PNG-making polyfill, would save reasonably small JPG files if the user right-clicks): https://sequentialread.com/better-portable-graphics-bpg-on-the-web-with-webassembly-wasm-and-serviceworker/ https://sequentialread.com/better-portable-graphics-bpg-on-t...