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.
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.
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.
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.