When to use “img,” “img@srcset,” and “picture” and “source”
At sum.cumo I almost got the reputation of a
srcset “hater.” I’ve disliked
srcset and the whole family of ideas around it from the start because doing the same thing (embed an image) for the same purpose (show an image of a particular meaning) several times (create images of the same meaning in different sizes, cuts, or formats) has usually looked like too much DX cost for too little UX gain to me. The goals of
srcset and the problems it tried to solve were clear, but that didn’t improve any of this bad taste.
Before I go on, here are examples for the three ways of embedding images that we’re going to discuss, simplifying MDN:
<!-- `img` element --> <img src=foo alt=bar> <!-- `img` element, `srcset` attribute --> <img srcset="foo-320w.jpg 320w, foo-480w.jpg 480w, foo-800w.jpg 800w" sizes="(max-width: 320px) 280px, (max-width: 480px) 440px, 800px" src="foo-800w.jpg" alt=bar> <!-- `picture` and `source` elements, `srcset` attributes --> <picture> <source media="(max-width: 799px)" srcset=foo-480w.jpg> <source media="(min-width: 800px)" srcset=foo-800w.jpg> <img src=foo-800w.jpg alt=bar> </picture>
Tooling, now, the card that developers habitually play, and that some of my colleagues have played, too, is not an always playable card to me—if you think about it, just because someone could produce garbage automatically wouldn’t make that an argument to produce garbage, and therefore it still behooves us to think about what we’re using tooling for *. Apart from that, I generally believe it’s useful to keep things simple yet also a tad difficult. You can tell how “tooling,” from this view, cannot be a satisfactory answer to the question whether and how to provide additional image sizes and formats.
Yet, is providing different image sizes, cuts, and formats indeed such a terrible thing? There doesn’t seem to be a single general answer. Here’s the perimeter as I see it, coming from two angles.
A Priority Perspective
If performance (UX) is the priority, then use
source, whichever yields better results or uses less code, as long as image weight savings are bigger than the HTML payload increase (compared to just
img). For an example where one should probably pass on a size, see the flamingo example on HTML.com (and skip output like flamingo3x.jpg).
If simplicity (DX) is the priority, use
img@srcset (easier than
source) or just
img (easiest overall).
If understandability and maintainability (likewise DX) are the priorities, just use
We’re working with some conditions here and I do grant DX that it can be a legitimate priority if UX is only mildly impaired. The simple rationale behind this is that a terrible DX will ultimately result in a terrible UX, so DX cannot be ignored.
A Payload and Tooling Perspective
If ultimate payload differences are insignificant, just use
If payload differences are moderate or if no tooling is available, use
If payload differences are large and tooling is available, use
source along with alternative image formats (like WebP) to achieve maximum performance.
❧ The point is, now, that it all depends †, that we still need to think, and that web development is still about probabilities. And, sure, that skepticism has nothing to do with “hating.” But everyone knows that.
Figure: Pretty much like running into
picture and his friends. (Copyright King Features Syndicate, Inc., distr. Bulls.)
Update (May 3, 2021)
The HTML specification, by the way, has a pretty nice section on embedding images and what to consider for it. It doesn’t match the advice I’ve been giving here, but—it’s the spec and this part of it is pretty detailed.
* For another good example of much blind toolism, look at favicons.
† Of course, this also applies to the
oversized-images feature policy.
I’m Jens, and I’m an engineering lead—currently manager for Developer Experience at LivePerson—and author. I’ve worked as a technical lead for Google, I’m close to W3C and WHATWG, and I write and review books for O’Reilly. I love trying things, sometimes including philosophy, art, and adventure. Here on meiert.com I share some of my views and experiences.
If you have a question or suggestion about what I write, please leave a comment (if available) or a message. Thank you!
Maybe this is interesting to you, too:
- Next: Sources 2019
- Previous: 13 Leadership Mistakes and How to Avoid Them
- More under Web Development, or from 2019
- Most popular posts
Looking for a way to comment? Comments have been disabled, unfortunately.
Get a good look at web development? Try The Web Development Glossary (2020). With explanations and definitions for literally thousands of terms from Web Development and related fields, building on Wikipedia as well as the MDN Web Docs. Available at Apple Books, Kobo, Google Play Books, and Leanpub.