Having the server decide the image format based on the accept header is simpler. Services like https://imagekit.io/ (no affiliation) can do that for you.
Yes, a smart server (that does more than serve static image assets) can do the heavy lifting and alleviate some of the HTML markup complexity.
It has the `Accept` header as a guide to what image formats the client supports, and with Responsive Image Client Hints[1], it can opt into more info from the client (device pixel ratio, image layout width, viewport width).
Without relying on server features, `<picture>` with `<source type='…'>` is the way to serve images in newer formats without breaking in less capable browsers.
It’s interesting that `image-set()`, the CSS sort-of counterpart to `<picture>`, bakes in the media type along with the resolution in a single syntax [2]. Which you could potentially see happening in `srcset`, but it makes the descriptive/prescriptive boundary a bit blurry, so it would complicate things IMO.
It has the `Accept` header as a guide to what image formats the client supports, and with Responsive Image Client Hints[1], it can opt into more info from the client (device pixel ratio, image layout width, viewport width).
Without relying on server features, `<picture>` with `<source type='…'>` is the way to serve images in newer formats without breaking in less capable browsers.
It’s interesting that `image-set()`, the CSS sort-of counterpart to `<picture>`, bakes in the media type along with the resolution in a single syntax [2]. Which you could potentially see happening in `srcset`, but it makes the descriptive/prescriptive boundary a bit blurry, so it would complicate things IMO.
[1]: https://wicg.github.io/responsive-image-client-hints/ [2]: https://developer.mozilla.org/en-US/docs/Web/CSS/image/image...