Container queries can’t be used in the sizes attribute for responsive images. Here, Jason breaks down why that is (spoiler: it’s the lookahead pre-parser) and segues into a truly long term solution: a “magical” image format.
If you’ve ever thought it felt weird to put media conditions inside the HTML for responsive images, this will resonate.
Addy takes a deep dive into making sure your images are performant. There’s a lot to cover here—that’s why I ended up splitting it in two for the responsive design course: one module on responsive images and one on the picture element.
Last month I wrote about writing on web.dev. At that time, the first five parts of a fourteen-part course on responsive design had been published. I’m pleased to say that the next five parts are now available. They are:
It wasn’t planned, but these five modules feel like they belong together. The first five modules were concerned with layout tools—media queries, flexbox, grid, and even container queries. The latest five modules are about the individual elements of design—type, colour, and images. But those elements are examined through the lens of responsiveness; responsive typography with clamp, responsive colour with prefers-color-scheme, and responsive images with picture and srcset.
The final five modules should be available later this month. In the mean time, I hope you like the first ten modules.
Did you know there’s an imagesrcset attribute you can put on link rel="preload" as="image" (along with an imagesizes attribute)?
I didn’t. (Until Amber pointed this out.)
Chris has put together one of his indispensable deep dives, this time into responsive images. I can see myself referring back to this when I need to be reminded of the syntax of srcset and sizes.
A nice succint explanation of using the srcset and sizes attributes on the img element—remember, you probably don’t need picture and source elements if your use case is swapping out different sized versions of the same image.
One caveat thought: you do need to know the dimensions of the images. If you’re dealing with unknown or user-generated photos, that can be an issue.
Remy has an excellent improvement on that article I linked to yesterday on using srcdoc with iframes. Rather than using srcdoc instead of src, you can use srcdoc as well as src. That way you can support older browsers too!
This is a clever use of the srcdoc attribute on iframes.
Some tips for getting responsive images to work well on the Apple Watch:
- test your layouts down to 136-
pxwide- include
300w-ish resources in your full-widthimg’ssrcsets- art direct to keep image subjects legible
- say the magic
metawords
Tim explains why that neat trick of making a really big JPEG with quality set to 0% is no longer necessary, and how the savings you make in bandwidth with that technique are nullified by the expense of the memory footprint needed.
Some great ideas here about using metaphors when explaining technical topics.
I really like these four guidelines for good metaphors:
These icons-as-a-service could be really useful for making quick’n’dirty HTML prototypes.
Jason revisits responsive images. On the whole, things are looking good when it comes to browser support, but he points out that scrset’s precursor in CSS—image-set seems to have dropped off the radar of most browser makers, which is a real shame.
The transcript of a great talk by Wilto, focusing on responsive images, inlining critical CSS, and webfont loading.
When we present users with a slow website, a loading spinner, laggy webfonts—or tell them outright that they‘re not using a website the right way—we’re breaking the fourth wall. We’ve gone so far as to invent an arbitary line between “webapp” and “website” so we could justify these decisions to ourselves: “well, but, this is a web app. It… it has… JSON. The people that can’t use the thing I built? They don’t get a say.”
We, as an industry, have nearly decided that we’re doing a great job as long as we don’t count the cases where we’re doing a terrible job.
A great primer on using srcset and picture. I think I’ll be referring back to this a lot.
Following on from that post of Jason’s I linked to, Chris also emphasises that, for most use cases, you probably only need to use srcset (and maybe sizes), but not the picture element with explicit sources.
It’s really, really great that people are writing about this, because it can be quite a confusing topic to wrap your head around at first.
Jason points out that the picture element might not be needed for most responsive image use cases; the srcset and sizes attributes will probably be enough—that’s what I’m doing for the photos on my site.
WebKit nightlies now have support for srcset. I’m pleased to see that it’s currently constrained to just handling the case of high-density displays; it doesn’t duplicate the media query functionality of picture.
I’ve always maintained that the best solution to responsive images will be some combination of srcset and picture: they each have their strengths and weaknesses. The “art direction” use case is better handled by picture, but the “retina” use case is better handled by srcset.
Wilto does an excellent job of summarising the current state of responsive images, highlighting Florian Rivoal’s compromise proposal that combines the best of the picture element with the best of srcset.
There’s a great article by Wilto in the latest edition of A List Apart. It’s called Responsive Images: How they Almost Worked and What We Need.
What all I really like about the article is that it details the the thought process that went into trying working out responsive images for the Boston Globe. Don’t get me wrong: I like it when articles provide code, but I really like it when they provide an insight into how the code was created.
The Filament Group team working on the Boston Globe site were attempting to abide by the two rules of responsive images that I’ve outlined before:
There are three reasons for this: performance, performance, performance. As Luke put it so succinctly:
Being a Web designer & not considering speed/performance is like being a print designer & not considering how your colors will print.
That said, I came across a situation recently where loading both images for desktop browsers could actually be a pretty good thing to do.
Wait, wait! Here me out…
Okay, so the way that many of the responsive image techniques work is by means of a cookie. The basic challenge of responsive images is for the client to communicate with the server (and let it know the viewport size) before the server starts sending images. Because cookies can be used both by the client and the server, they offer a way to do that:
There are some variations on this: you could initially route all image requests to send back a 1x1 pixel blank .gif and then, after the page has loaded, use JavaScript to load in the appropriate image for the viewport size.
That’s the theory anyway. As Mat outlined in his article, there’s a bit of a race condition with the cookie being set by the client and the images being sent from the server. New browsers are doing some clever pre-fetching of images. That means they fetch the small images first, violating the second rule of responsive images.
But, like I said, in some situations that might not be so bad…
Josh is working on a responsive project at Clearleft right now—and doing a superb job of it—where he’s deliberately cutting the server-side aspect of responsive images out of the picture. He’s still starting with the small (mobile) images by default and then, after the page has loaded, swaps them out with JavaScript if the viewport is wide enough.
Suppose the small image is 20K and the large image is 60K. That means that desktop browsers are now loading 80K of images (instead of 60). On the face of it, this sounds like really bad news for performance… but because that extra 60K is being downloaded after the page has downloaded, the perceived performance isn’t bad at all. In fact, the experience feels quite snappy. Here’s what happens:
The markup contains the small image as well as some kind of indication where the larger size resides (either in a query string or in a data- attribute):
<img class="photo" src="basestar.jpg" alt="a spiky seed" data-fullsrc="basestar-large.jpg">
That’s about 240 by 180 pixels. Now for the large-screen layout, we want those pictures to be more like 500 by 375 pixels:
@media screen and (min-width: 50em) {
.photo {
width: 500px;
height: 375px;
}
}
That results in a “blown up” pixely image.
Once the page has loaded, that small image is swapped out for the larger image specified in the data- attribute.
Large-screen browsers have now downloaded 20K more than they actually needed but the perceived performance of the page was actually pretty snappy:
Does that sound familiar? This is exactly what the lowsrc attribute did.
I’m probably showing my age by even acknowledging the existence of lowsrc. It was a proprietary attribute created by Netscape back in the days of universally scarce bandwidth:
<IMG SRC=basestar.jpg LOWSRC=low-basestar.jpg ALT="a spiky seed">
(See how I’m using unquoted attributes and uppercase tags and attributes for added nostalgic value?)
The lowsrc value would usually be a monochrome version of the image in the src attribute.
And we only had 256 colours to play with. You tell that to the web developers today …they wouldn’t believe you.
Seriously though, it’s funny how problems from the early days of the web have a habit of resurfacing. I remember when Ajax was getting popular, all the problems associated with frames rose from the grave: bookmarking, breaking the back button, etc. Now that we’re in a time of small-screen devices on low-bandwidth networks, we’re rediscovering a lot of the same issues we had when we were developing for 640 pixel wide screens with 28K or 56K modems.
Ultimately, I think that what the great brainstorming around fixing the problems with the img element shows is a fundamental impedance mismatch between the fluid nature of the web and the fixed pixel-based nature of bitmap images. We’ve got ems for setting type and percentages for specifying the proportions of our grids, but when it comes to photographic images, all we’ve got is the pixel—a unit that makes less and less sense every day.