If you use the <picture> element [0], then you can specify a MIME type on the srcset. Browsers will then use this to load an image they support - so if you have a set of pictures with a MIME type of image/webp and others with image/jpeg, WebP will be used by those browsers that support it and JPEG by those that don't. There's a good example at [1].
Alas although most browsers support the picture element, IE11 is the notable exception [2] and a polyfill is required.
You can use HTML <picture> elements to provide provide multiple image format versions for an <img> element e.g. preferentially use webp if browser supported, and fallback to using a widely supported format if not. Sounds like doing that might be of interest to you.
> I'd like to support it in my own websites, but I literally can't since a huge chunk of visitors use Safari.
Wouldn’t using the <picture> element[0] allow this this? It’s pretty widely supported (every browser that supports WebP and Safari)[1] and allows a fallback to a JPEG in an <img> tag.
Would this be susceptible to tracking issues? E.g. place a hidden picture that loads WebP or PNG otherwise, to track which users support it and which don't
I would assume that’s entirely possible, but something like this could be done using the HTML5 <video> or <audio> elements for video or audio codecs (there’s even a DOM API to do it! [0]), and some browsers advertised WebP support via the HTTP Accept header [1]. For tracking, I’d assume it’s not very useful these days apart from determining who’s using Safari?
Edit: Not to mention that the onerror event handler on the <img> tag has always been able to find out if an image didn’t display [2].
The only hope seems to be mobile linux initiatives like PinePhone, etc. But I'm not holding my breath.