Just a follow up thought on this point, but Chrome and Firefox have both adopted AVIF and apparently it was added to the nightly versions of Safari about 6 weeks ago, so it could be here fairly soon.
AVIF is lighter than either Jpg or WebP and it looks like the adoption will be a lot faster, so it stands a better chance of being the default option. We are still left with the question of legacy Mac OS versions with Safari, but a year or so from now we may have a very different situation in terms of web development.
Had heard similar on another forum, that WebP was 10 years old and only just getting wider spread support but with AVIF on the near horizon WebP may just be a temporary stepping stone.
WebP would no doubt have gained more rapid adoption if Apple had decided to support it many years ago and I suspect this was more about corporate politics than anything else. There is some more insight here on AVIF.
I’ve just found an online converter from Jpg to AVIF.
I just ran a quick test with a grainy old film scan and at 1000 pixels it weighed in at just 76kb with AVIF compared to 175kb for Jpg. Dragging the image in Chrome and it just works, so that is already more than half the market.
Next I ran a test on a large 6000 pixel image with plenty of detail. Exported for web as Jpg from Affinity Photo that came out at 3.5mb. As AVIF it’s 912kb. It might well be that further tweaks with an app converter could yield even better results.
WebP requires Big Sur for compatibility with Safari, hence the fallback debate. If AVIF works just works in Safari and is not dependent on the OS then it might be possible to adopt AVIF quickly and drop Jpg entirely, however I note that the AVIF images I downloaded had no preview image inside the finder.
Might be time to take Safari nightly for a spin and see what happens there with AVIF. Looks like there is no version for Mojave but it exists for Catalina or Big Sur.
In theory the same approach could be used as with the WebP images using the approach of @smileBeda. The key difference here would be if AVIF is enabled at a browser level in Safari, rather than based on the latest OS.
If we find that AVIF just works with Safari 14 I think most of us could happily drop Jpg entirely before long with no need of a fallback. Just use AVIF instead of Jpg and have faster loading sites.
Even though, I don’t yet understand what you have done Playing with the Modernizr, I’m grateful for the time you took to look into making this work.
In your example: if AVIF cannot be used then the script selects a compatible format, no webP than the png is used.
I assume the same for AVIF, when it is not compatible than webP is used. If webP can’t be used than png or jpg is used
I find it not strange and would have considered it strange had you broke your tendency.
The difference between a walled garden and open development is, while users wait for support to be provided fallback or not, what is being debated here in both your threads (WebP/AVIF) are already being used by many outside the walls freely. Web developers rarely need to wait to leverage cutting edge benefits for users. Even though Safari tries it’s best to be the new IE, it thankfully does not hold back the web successfully in the same manner.
Perhaps it has different names?
Interestingly the first comment here insinuates that they achieved it using Modernizr.
Quite confused as of how, since it doesn’t have the detector inbuilt, but again, maybe it has a different name that I didn’t search for.
If so, the same easy approach can be taken as in my previous example and simply (after building and adding the specific JS) use the CSS classes (it will require you to upload both formats, a modern and a fallback) to check support and load images conditionally.
Yeah well… not really - not out of the box anyway. I’ve tried 3 different (major) libraries due to the thread here and all of them are of no use unless the modernizr one, which works. However that one didn’t offer AVIF Support as far I saw.
Of course one could craft such script… but it would require quite some work and probably add overhead we wouldn’t want.
The least invasive and most light I found was the picture approach with HTML. That is really fast, clean and requires no scripts but is not very dynamic as each and every mage markup needs to be addressed…
It would probably be a bummer to write such library as you outline, but you’d have to deal with a bunch of conversion on the fly, if you don’t want to force the “user” of that script to provide all 4 file types as fallbacks. And that again adds overhead, as well as site sizes would grow (because one would have to URL encode images or SVGs, for example, which is per se not a really nice thing to do)
No big luck for us this time I think.
Of course I might miss something, the internet is huge nowadays and there is almost anything for anything, so … maybe someone knows of some such script, I’d be eager to test it.
Hey I really do appreciate the time you,@smileBeda, take to inform us of all this really good information. Like you said maybe someone will share something they’re aware of.
