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

All that may be true, but the most relevant factor here is Google and Microsoft backing WebP. Google has the power to push through its own inventions due to Chrome's market share. If you want less of that, use Firefox.

Meanwhile, Mozilla hasn't given up on better formats, as the article points out.

Similarly, Google now picks the standards it likes, and everyone else is caught between the choice of investing in those or lose compatibility with Chrome. Not much of a difference.

You can easily replace Chrome, it's not even a platform default. You're forbidden from replacing Safari.

How does a web developer test for Android compatibility? I have been testing against Chrome only.

https://appleinsider.com/articles/18/10/05/firefox-gets-supp...

The Wikipedia article [0] says they started evaluating adding support in 2016. Following the source links to this bug report [1]. From a quick glance at the discussion there, it's not obvious to me that they've settled on adding in WebP support.

What we need is buy-in from Apple. Although I'd be much more excited about them adding WebM support so we can finally drive the last nail in the GIF coffin. Does anyone know why they pulled it out? If I had to take a shot in the dark, maybe it doesn't perform well on mobile or it consumes too much power?

Maybe this is a dumb question, but why will we be supporting both WebM and animated WebP? According to the Wikipedia article, WebP also has animation support.... But isn't that kinda redundant? Do they solve different problems? You can just create WebM containers without an audio stream.

While we're on the subject of adding new image formats to the web, does anyone know if there's any interest in adding FLIF support [2]? When it came out it seemed much more interesting to me, but it looks like it never picked up steam.

As an aside, can I just say fuck CNET? Here they used a shitty linking practice which I always find incredibly annoying. Instead of linking to primary sources, they add some useless tag links along with references to old CNET articles. How about linking to the relevant bug reports, asshole?

[0] https://en.wikipedia.org/wiki/WebP

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1294490

[2] https://en.wikipedia.org/wiki/Free_Lossless_Image_Format

From: https://developers.google.com/speed/webp/faq (Why not simply support WebM in <img>?)

WebM uses more memory, it is less widely supported, uses more resources when playing, and is currently less efficient compression-wise than WebP.

About FLIF, I was recently checking it and it's indeed a very interesting format. Notably because it can be used on any type of image. I assume it hasn't pickep up steam because it doesn't have the backing of any big sponsor. Google is pushing WebP, and introducing another format at this time is probably not worth it.

The progressive streaming is a cool trick, but if you actually use the progressive stream to embed lossy images in your web page, you end up with lower quality than if you had just used JPEG in the first place, never mind something newer. The difference was pretty stark.

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

Besides, modern cameras such as the Sony a7R II are already producing photos 8000 px wide, and the upcoming 100 megapixel cameras such as the Fujifilm will do 12000 px wide images. It's very easy to hit the limit if you're planning to shoot any panoramas.

[1] https://commons.wikimedia.org/wiki/User:Dllu

Anyways, webp is for websites not cameras..

> Even 4:2:0 is better than the sRGB usually used in PNG.

Better for what? Not for wide-color photographs or any kind of colored text, that's for sure.

https://9to5google.com/2018/09/14/youtube-av1-video-beta-chr...

[1] https://caniuse.com/#feat=heif

[2] https://github.com/Fyrd/caniuse/issues/3767

I actually don't think this about other formats - for instance MP3 is 25 years old and I think it's just fine to support it. It's patent free and its quality limit is all you need for many applications.

This isn't true for VP8, our eyes are just harder to please. (And On2 was never the best codec developer…)

I suspect they might be motivated by the rapid way in which HEIF seems to be taking over. My understanding is that comparatively, the patent situation of WebP is much better. If you're a company concerned about software patents on the web, it might suddenly seem that throwing your weight behind WebP as a way of avoiding the proliferation of HEIF is worthwhile.

AV1 is finalized: https://aomedia.org/av1-features/get-started/

I think there are a couple bugs and contradictions between the spec and reference implementation that are being ironed out, but the bitstream is now frozen.

Try the "clovisfest" test image here[0], with the most recent AV1 snapshot on the right, and MOZJPEG (the most advanced JPEG encoder on the market, AFAIK) on the left, with both set to the "Tiny" target bitrate (0.1bpp). Smooth, continuous grades look hideous on JPEG up to pretty high bitrates, and JPEG never quite reproduces hard edges or sharp specks properly; AV1 excels at both of these.

[0]: Image formats comparison <https://wyohknott.github.io/image-formats-comparison/#clovis...

WebP has its drawbacks, like no support for HDR content. AVIF supports it and Netflix would like to use it for video thumbnails.

[1] https://www.cnet.com/news/googles-webp-image-format-finally-...

[2] https://www.cnet.com/news/apple-ios-macos-tests-googles-webp...

I believe what WebKit introduced was the analogous CSS image-set property, which likely influenced the picture's element's development (but image-set still hasn't managed to escape draft-spec territory).

The ideal format would be HEIF but there's not a lot of conversion support out there, Imgix doesn't support it for instance.

https://bellard.org/bpg/

Also, one of the patent pools covering HEVC announced in 2016 that software-only implementations would be royalty-free:

https://www.prnewswire.com/news-releases/hevc-advance-announ...

Whether still-other licenses from other patent-holders might be necessary for software-only, in-browser decoding is unfortunately murky.

Had heard they are working on it. But had not heard a date?

Given how iOS Safari is the least standards compliant browser of our time (other than the now defunct IE), I'm surprised they even implemented webassembly & webRtc (they didn't implement the data channel)

That is not correct. I've used WebRTC data channels myself on iOS and it works fine.

Here's a simple WebRTC DataChannel demo that doesn't work on iOS 12.0 Safari

https://webrtc.github.io/samples/src/content/datachannel/bas...

Since you're not convinced, I looked into it a bit more, and the reason most of the available demos don't work is down to a difference in behaviour between Safari and other browsers, probably to do with address selection for the connection. WebRTC can leak private network configuration in some cases, so Safari seems to be pretty strict in that it requires `getUserMedia` to be called before allowing a data-channel-only to be established.

I made this into a small demo (https://codepen.io/anon/pen/GYrqGL) and you can see after a couple of clicks of 'connect' that a data channel connection is established and works as expected. This is a bit of a privacy/usability tradeoff. But data channels are very much implemented in Safari.

Cheers