…I thought that, if you offer a browser an image in `src` it *does* understand and others in `srcset` that it doesn’t, it will ignore the latter. But my ageing iOS Safari doesn’t do that. For some reason, it will try to deploy a `srcset` specified avif even though it cannot render an avif. How fked is that?

Turns out the solution, which I did not know about, but @wbrowar kindly alerted me to, is to use `picture`, but I’ve only ever used `picture` for viewport conditional *art direction*…

…Now it’s possible that my ageing iOS Safari has a bug and is doing things it shouldn’t, which has since been fixed, but I’m kind of not interested cos:

- software has bugs, that ain’t changing
- I’m not getting a new smartphone
- there’s another approach to all this, which I’m coming to, but not yet.

First, here for backwards resilience is what I should be doing with avifs:

<picture>
<source srcset="filename.avif" type="image/avif">
<img src="filename.jpg">
</picture>

…My ageing iOS Safari does the right thing with that code. It ignores the avif it can’t handle and renders the JPEG.

Better browsers use the avif.

But there’s a bigger picture here than just my previously insufficient understanding and the fact that I’m getting old:

- the web front end is getting more complex
- the wrongheaded assumption of evergreen browsers is compounding this
- the slowdown in new device purchase, if not yet here very much, is for sure gonna gather pace

which means…

…An ever growing mountain of either (wrong) assumptions about what tech a user has, or a growing slag heap of conditionals to test for.

Which is how I come to be revisiting:

- @jimniels’s ‘Website fidelity’ approach blog.jim-nielsen.com/2022/webs… which is in turn informed by…
- Kyle Simpson’s 2019 talk ‘FOUC, and the Death of Progressive Enhancement’: youtube.com/watch?v=SiYFh7wutT…

…The point being, as Jim says,

“a world where you don’t need to remember separate domains based on the experience you want. Rather, you visit the same domains you always visit, but with the ability to express a preference for the fidelity of experience you want/need in any given moment.”

And when we put this together with a world in which the user might have :has, avif, or container query capability, or they might not, we can offer them lower-fi branches to sit on…

…Sure, we can do lots of multi-faceted testing, and diligent use of @\supports, etc, and we should, but…

as the web complexifies further, that becomes harder to do, and when a web enterprise doesn’t have a whole suite of 10x developers available to it, shit falls through the cracks.

So instead of *only* building interfaces that test the fk out of every conceivable device permuation, or worse, assume everyone has the latest and greatest (which is all too common), we can relax a bit into…

…A final thought for now. All this might seem superfluous because people are wrapped up in the myth of progress and the inexorable upgrade path.

But I think that is changing, or about to change. It certainly will change. People will hold onto devices longer.

And then the device landscape becomes *way more divergent*. And vibe coding ain’t gonna have fixes for that, and neither are developers being squeezed by fked up LLM-loving management