The Forgotten Responsive Images Spec: image-set()

Written by Jason Grigsby on

Now that responsive images have landed in Chrome and Opera, I’ve started working on a flowchart to help people decide how to use these new features.

This work led me to wonder what ever happened to the image-set() specification.

For those who haven’t heard of the image-set() specification, it was a precursor to srcset which is now part of the responsive images specification. It was originally proposed in February 2012, and WebKit-based browsers shipped prefixed support for it in August of the same year.

The are a few differences between srcset and image-set(), but the biggest difference is that image-set() deals with CSS images whereas srcset is an attribute on the <img> element.

How we forgot about image-set()

In 2012, the image-set() spec was still under development and we were cautioned against using it at the time. Because media queries were available in CSS, handling CSS images in responsive designs wasn’t as difficult as handling responsive images in HTML itself.

So the Responsive Images Community Group focused on how to solve the <img> problem. And I gradually forgot about image-set() thinking that it was moving forward in the CSS Working Group and browsers.

It seems that I may not have been the only one who forgot about image-set() because despite being two years older than <picture>, it is still only supported under prefixing in Chrome and Safari.1 Worse, it isn’t on the roadmap for either Internet Explorer or Firefox.

Why we need image-set()

We need image-set() for the exact same reasons we need srcset and sizes. Whenever we are dealing with a CSS image that fits the resolution switching use case instead of the art direction use case, we should be using image-set() instead of media queries.

In fact, you can take nearly everything I wrote in Don’t Use <picture> (most of the time) and substitute image-set() for srcset and media queries for <picture> and the same logic applies.

We need image-set() for resolution switching because it gives browsers the choice of what size image source will work best. And in cases where all we are dealing with is resolution switching, the browser is better informed than we are as web authors.

Help get image-set() into browsers

We need your help to make sure that image-set() is implemented in browsers. Help us by voicing your support and ask browsers to prioritize this feature:

Image-set() is a key piece of having a comprehensive responsive images solution in browsers. It has been languishing too long. Let’s get it back on track.

  1. Eugeny Vlasenko built a nice test for image-set() as well as publishing the results of testing a bunch of browsers and their support of the spec.
Jason Grigsby

Jason Grigsby is one of the co-founders of Cloud Four, Mobile Portland and Responsive Field Day. He is the author of Progressive Web Apps from A Book Apart. Follow him at @grigs.

Never miss an article!

Get Weekly Digests


I’m unclear as to why the horror about double downloading.

Suppose that you decide that an image will be usable with a stretch of 20% and a shrinkage of 50%. A 300 pixel wide x 50 pixel high bannaer then is 15,000 pixels. Go to a retina display, and the same phone is downloading a 900 x 150 pixel image — 135,000 pixels. Downloading the wrong image is an 11% penalty. For larger displays the initial image download is an even smaller fraction.

AND this puts something on the screen *really* fast.

AND it gives the server some indication of the bandwidth to the client.

In essence the page loads twice — once for the smallest image, once for the correct image.


I ran into the semantic content issue before in discussions of using CSS background images. What if the image is present in both the CSS background (adjusted for media) but also in the markup (which gives it semantic content.) Since the image has been previously downloaded, it costs nothing when hit by the img tag.

The latter still has the problem of multiple resolutions with one URI, resulting in problems both for indexes and CDN networks.

Let’s discuss your project! Email Us