jaffathecake

Yep. Look at the replies. He's challenged on it, and doubles down. It's not a joke.

The Cloudinary one is written by one of the leads of the JPEG XL project.

I disagree. Making things slower for everyone due to this edge case is a bad tradeoff. Web APIs exist to let you know when zooming in happens. You can swap to a higher resolution, or even tiled image in these cases if you really care about this use-case.

Browser vendors want their browser to be safe to use. If we encourage users to essentially bake their own browser from a hodge podge of unverified third party code running at high privilege, we don't meet that goal.

Plethora means an excessive amount, so I disagree.

Adding formats to the browser gives us more code to maintain, increases the binary size, and increases the attack surface area. That's why, at Firefox, we insisted on a Rust decoder.

No. I'm working with Google on this. But you might be able to find a preview of the next version.

I'm not aware of any browser that cannot render AVIF 4:4:4. Given that avifenc outputs 4:4:4 by default, I don't expect that to change.

This is why I added the wasm fallback. The question was why I didn't serve PNGs to everyone.

That's what I'm talking about. JXL support landed in 158.

It's not mandatory. But if you don't use it, the browser may select a source it cannot play.

As someone putting an image on a web page, why would I make detection of artifacts easier?

The images in the article max out at the maximum size I'd want them displayed.

'high quality' and 'very high quality' are different things.

> AVIF images have a max size of 8192x4352

This isn't true btw. The format supports up to 64k x 64k, although browser decoders currently fail beyond 16k x 16k.

Not sure when you'd serve something like that on a web page though.