Posted by farlight 7 hours ago
JPEG XL doesn't have that benefit, while sites adoption is arguably a worse issue than browser adoption.
To demonstrate the point even for AVIF itself - it has been in the browsers for a while. Can you use it on common sites? Good luck if you can, even major sites like GitHub and GitLab have issues with it due to some site code depending on hardcoded list of known formats or other similar problems.
ISO-BMFF container is bloated and needlessly complicated. AVIF decoders didn't even want to reuse existing MP4 libraries for it due to all the baggage it brings, and implemented their own minimal parsers.
AVIF would have been better off with a simple wrapper similar to RIFF/PNG or extending AV1's own OBU header (which for inexplicable reason gets its data duplicated inside the HEIF container and then implementations are required to verify that both copies agree!)
I hope AVIF will skip AV2. We don't need yet another almost-identical format to migrate to.
Many other image formats are. AVIF uses HEIC, the same container that HEIF does.
> when AV2, AV3 etc. will come out, there won't be a need to go through another very difficult phase of sites adoption - it will still be AVIF just with newer codec inside, and it will be just up to browsers to catch up on newer versions and newer codecs will address technical needs as times goes.
Fingers crossed, but AV2-based AVIF specs haven't even been finalized, so who knows.
With no codec for a new compression algorithm, it does not matter if the browser can read the container, you still see the "broken image" icon on your display.
You as user can then upload AVIF images to wherever images on the site are processed. And after that, let's say when newer codec inside AVIF will get a good browser coverage, you'll be able to start using it without waiting another decade for GitHub to pipe it through their site code.
For formats without a container, it's always a two step process. Browser coverage first, then another huge period of sites support catching up.