Thanks for pointing this out. I’ll add a fallback using the “picture” element (TIL).

I also use some javascript to delay rendering until the browser window stays on an image. That could very well be introducing some wonkiness.

you should use the built in lazy loading https://caniuse.com/loading-lazy-attr or intersection observer for this https://developer.mozilla.org/en-US/docs/Web/API/Intersectio...

Is there really a need for lazy loading a blog page over just providing a height and width attribute and letting the browser work it out?

Not a need, per se, but it's an SEO recommendation according to web.dev measure. Both are actually recommended.

Odd. Displays fine on my Safari 14.1.2. Checked and the images do appear to be web for me as well.

Current Big Sur release, not a Beta.

Safari 14.1.2 on latest Catalina doesn't render

Only safari on big sur has webp support.

That's very strange. Is this a versioning problem (i.e. Catalina not being supported anymore?) or is there some kind of hardware restriction?

From what I can find, Catalina should still be supported for more than a year from now, right?

Edit: well, that's bizarre. Caniuse.com [0] lists the same restriction, WebP is only available from Big Sur onwards. And then people wonder why nobody likes developing for Safari.

[0]: https://www.caniuse.com/?search=webp

Safari uses AVFoundation and ImageIO for handling video and image data respectively. These frameworks are tied to OS releases. This ends up meaning the latest Safari on an older OS might not handle some formats/codecs.

So Safari gets free accelerated handling of new formats and codecs but only when the underlying OS supports them.

For media formats the support is often dependent on the OS. It's been that way forever (ask anyone deploying video in early html5 and getting it to work cross-os and cross-platform). I guess it's more expected with videos, but images are (usually) handled the same.

Maybe with hardware decoding, but software decoding is often done in browsers when hardware support is not available.

I suppose Apple doesn't want to include a software fallback for platforms where hardware isn't available to discourage developers from using the format. It's not like Apple would need to write any complicated decoding algorithms when there's already an open source implementation that's free to use.

H264 didn't work in FF on MacOS and Linux (but it still worked on windows) until v34 (and it only started working because Cisco donated a license), Ogg Vorbis only works on MacOS 11.3 or later in safari (and it also depends on which container you use), HEVC in IE/EdgeHTML depended on hardware (with no fallback to software whatsoever), AV1 in FF65 only worked on Windows, AV1 in FF66 only worked on Windows and MacOS, chrome on android 2.3 required you to specify a m4v without mime-type, but doing it with mime-type worked fine on desktop chrome.

I'm just saying it's not unprecedented to have the same browser version supporting different audio/video/image formats depending on OS or hardware.

For image formats it's not as usual, but if someone is making a site only supporting webp then I'd assume they'd look up some support matrixes beforehand.

That's because of the licensing issues, especially H.265/HEIF. AV1 has barely any hardware support and software decoding is terrible for performance, so while many browsers can easily build in support, it's not really worth it to enable it by default.

VP9 and WebP patents are all granted freely by Google. WebP images aren't as terrible for power consumption even in software because the browser doesn't decode 60 of them every second.

Regardless of that it's not uncommon to have the same browser version support different media codecs/formats.

Regarding the examples, when it comes to Ogg Vorbis there is no issue with software decoding (it's software everywhere), AV1 was granted software decode support on some OS'es but not others in the exact same browser, version and hardware (and IIRC it's the encoding perf that is especially bad for AV1, not decoding) and the chrome on android issue also shows how legal or hardware issues are not the only things limiting what is available (it can also be bugs that just stay around).

All I'm saying is that testing for browser version A is not a surefire test. Either check the support or test on browser A version B on OS C version D on hardware E (for each of the A/B/C/D/E variants) or just stick with what works across the board. Either way you probably won't end up shipping a site with only webp support.

Works fine in the latest Safari.