My take: WebP is not a good format. It was a clever quick hack betting on the older generation of WebM taking over the world, and that hasn't happened.<p>- It doesn't compress well. It's <i>twice the size</i> of HEVC. We have similarly-performing VP10 now, but WebP is based on VP8, which is a 2006 codec that has lost to a 2003 codec in the market.<p>- It's actually 2 formats under one name. WebP has VP8 and its own lossless thing separately. JPEG-XR, JPEG 2000 and FLIF can use the same algorithm for both lossy and lossless.<p>- The lossy variant (which is the only interesting one) does not support full-resolution color. You have to live with chroma subsampling which messes up anything with sharp saturated colors.<p>- It's 8 bit only. This is too little for wide gamut displays which are becoming more common.<p>- It doesn't support progressive decoding at all (misses out on awesome HTTP/2 optimization that gives illusion of all images loading instantly).<p>- The alpha channel can only use lossless encoding. It's a big problem for non-binary transparency (complex shadows, smoke). That's <i>the</i> major usecase for it on the web, and that's the least efficient variant of WebP.<p>- It suffers from generation loss <i>waaay</i> more than any format.<p><a href="http://flif.info/lossy.html" rel="nofollow">http://flif.info/lossy.html</a>
My two cents: Which version of webp should Firefox support? There are 3 major versions, and the subtleties in the 'extended' webp is only traceable through the releases of Chrome.<p>further, how can I tell which client supports which version of webp? `Accept: image/webp` is insufficient because it doesn't tell me which version or subset of features this client uses. Take for example, ios9b1 where webp was thought to have accidentally been available through CoreImage. It only supported WebP basic. But how would a server know this?<p>Lastly, webp is not setup to be successful for the next set of requirements: it is 8bit per channel color only (can't do 10bit needed for P3 or rec2020). It can't do full chroma subsampling (4:4:4). And the list goes on. It was a good first start, but it needs much more work before it can break out of the Google grip and get wide support.
That's an old, closed reddit post.<p>They have been actually actively implementing .webp support since August:<p><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1294490" rel="nofollow">https://bugzilla.mozilla.org/show_bug.cgi?id=1294490</a>
The top comment does a good job of explaining the reasoning. That said, since then more browsers (IIRC Safari) have announced that they are adding support, and the use case of lossy images with an alpha channel is important for games.<p>This has caused Mozilla to revisit the issue:<a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1294490" rel="nofollow">https://bugzilla.mozilla.org/show_bug.cgi?id=1294490</a>
If you're willing to deal with the development overhead of creating/storing multiple formats, which if you super care about optimized content serving you're doing anyway for sizes, then just use a picture element with fallback sources.<p>Progressive enhancement applies to more than just JS, and we've already been provided with a standard way to not have to care about browser support.
This is what the accept header is for. Browsers should implement whatever they feel is best for performance, security, maintainability, etc. Then the server should look at the accept header for a resource and serve a format the client can understand.<p>Imgix offers this as "Automatic Content Negotiation": <a href="https://docs.imgix.com/tutorials/improved-compression-auto-content-negotiation" rel="nofollow">https://docs.imgix.com/tutorials/improved-compression-auto-c...</a>
Politics. There is a compile-time flag in firefox that allows it to use system codecs (for images as well as video). I ran a self-built Firefox for some time that had this enabled. Mainly to view media files on the local network, and because there was a time where people were putting up some files that chrome could open, but not firefox (I forgot what that format was - maybe it was even webp).<p>If you enable the flag (or, disable the built-in whitelist), then Firefox uses GStreamer (and I believe DirectShow on Windows or Quartz on macOS, but I'm not sure) to display the videos.<p>There also used to be the option of using MPlayer as a plugin, but NPAPI support was unfortunately removed.
Is there a reason why a web browser could not integrate imagemagick (or equivalent) in order to support a "kitchen sink" set of formats?<p>Why not have Amiga IFF images on the web? ;)