Then again, libjpeg-turbo could probably be dropped if we spend some effort on making libjxl also decode jpegs (and encode them, since browsers also need to do

Then again, libjpeg-turbo could probably be dropped if we spend some effort on making libjxl also decode jpegs (and encode them, since browsers also need to do be able to do that for jpeg). I think that could reduce the net cost of adding jxl quite a bit — libjpeg-turbo has quite some code and API functions that browsers don't actually need at all, and all it really needs to do is already there in libjxl. So a variant of the "two for one" argument that justifies AVIF can also be used to justify JXL, since JPEG is needed anyway, even more so than AV1. Also I am not so sure if the delta between AV1-only and AVIF is _that_ small, after all you do need to take care of alpha, color management, HDR, animation, and I suppose quite different code paths to get the decoded pixels in the right place than what is already there for the video case. Plus it looks like new things are still getting added to avif, like YCoCg-R and progressive previews, so it feels like it's a bit of a "moving target" spec like webp was in the early days. I see quite a few opportunities for bugs, different levels of support between different browser (versions), etc, that are not caused by AV1 itself but just by AVIF.