This doesn't look Mac specific. Routing to Media.

Thanks for filing the issue!

@Reporter: If possible could you please provide sample test file/URL that reproduces the issue which helps us in further triaging it.

Thanks!

For the webp format we declared it stable with the 1.0.0 release though it had been since the addition of animation. We have no plans to further modify the format so this discussion might better be had about future formats. The AOMedia group is investigating a next-gen format currently. It might be good to join in that discussion, I can have someone reach to you if they haven't already.

For the versioned mime/type, I think you'd still be in the situation where you had to UA sniff for support across versions [1]. That also wouldn't address any implementation fixes or changes in the browser itself. Somewhat recently we changed the looping behavior for webp for instance [2].

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=854824
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=649264

Bad copy and paste in comment #7, sorry about that.

[1] https://developers.google.com/speed/webp/faq

Re: jzern —

Even if the WebP format remains stable forevermore, the fact that there are older browsers out there requesting with `Accept: image/webp` when they can’t actually accept all WebPs makes this a problem for us when delivering WebPs, now.

If new Chromiums began broadcasting something that differentiated them from older Chromiums – for instance, `Accept: image/webp;codecs=libwebp1.0` – we (Cloudinary) could stop UA sniffing, and instead make decisions about whether or not to send animated, lossless, or transparency-containing WebPs based solely on the `Accept` header:

`Accept: image/webp;codecs=libwebp1.0.0` → we know that we can respond with animated/transparent/lossless WebPs
`Accept: image/webp` → we do not know that we can send anything other than a baseline lossy WebP. Use other formats for images that require animation/transparency/losslessness.

User-Agent sniffing is hard to do well – and getting harder to do at all [1]. Chromium making this change would:

1. establish a precedent for how to deal with moving-target formats, as you suggest (we would love to join those discussions re: AVIF! A mechanism like this could also help browsers/servers roll out support for older, never-universally-adopted things like arithmetically-coded-JPEGs [2].)
2. let us stop UA sniffing to work around issues with WebP, right now

---

Re: viswa.karala –

Consider the <img> tag here:

https://codepen.io/eeeps/pen/zaWbrv

This uses Cloudinary’s `f_auto` feature, which format-switches automatically, sending different clients different images (each according to its ability). So, if you load this page in Safari, you’ll get an animated gif; if you load it in Chrome 32+, you’ll get an animated WebP. Originally, *any* browser that sent `Accept: image/webp` would receive an animated WebP, but customers complained that older Android phones were getting broken images, so we had to start UA-sniffing in order to know when we could/could not trust that `Accept` header.

---

[1]: https://twitter.com/rmondello/status/943545865204989953
[2]: https://bugs.chromium.org/p/chromium/issues/detail?id=669501#c8

> 2. let us stop UA sniffing to work around issues with WebP, right now

That's true at the cost of more modern chromiums M32-M70 being penalized unnecessarily for an even older set of browsers.

Extending the accept header comes at a cost of request size, which Chrome has been sensitive to in the past. And as said pinning to a decoder version doesn't eliminate issues in the wrapper implementation. I think there are lessons in webp deployment that can be applied in the future, but any changes to existing behavior would require input from others, a few of which I'm including on cc.

Here's how we're looking at the costs:

Broken images
	= completely unnacceptable, avoid at all costs

Sending an (e.g., 30MB) animated gif when a (e.g. 15MB) lossy animated WebP would have worked
	= very bad

5? 10? extra bytes on every image HTTP request
	= insignificant

We want a solution here that lets us confidently NEVER send anyone broken images, and minimizes the number of times we send people megabytes of extra data.

You're correct that the change we're suggesting would lead to Chromes 33-70 suffering with a lot of extra data. That's a cost we're willing to pay to be certian that we're never ever sending anyone broken images, and that every browser going forward that can handle aWebP, will get it.

We're also weighing that cost against the assumption that the UA sniffing that we're doing now is  excluding a number of non-Chrome clients from those gains... We'll start gathering some data internally to see how many browsers that `Accept: image/webp` are not getting WebPs at all because they don't fit the UA filters we've attatched here.

As WebP support grows (e.g., Edge is about to adopt it), UA sniffing around this issue is going to get much harder. We're advocating for this issue to be addressed now. 

Just drawing attention to Mark Nottingham's suggestion to use a new subtype to differentiate, over on the WICG thread:

https://discourse.wicg.io/t/more-specfic-mime-types-for-images/2852/4?u=eeeps