Responsive Images Community Group
Skip to toolbar
Skip
My W3C Account
Responsive Images Community Gr...
Responsive Issues Community Group
This group was closed on 2023-04-07.
Our goal is a markup-based means of delivering alternate image sources based on device capabilities, to prevent wasted bandwidth and optimize display for both screen and print.
Note: When the group expanded its scope in November 2014, it changed the name from "Responsive Images" to "Responsive Issues."
ResponsiveImagesCG/
Group's public email, repo and wiki activity over time
Note: Community Groups are proposed and run by the community. Although W3C hosts these
conversations, the groups do not necessarily represent the views of the W3C Membership or staff.
Final reports /
licensing info
Date
Name
Commitments
2012-07-02
Picture Element Proposal
Licensing commitments
Welcoming the WICG
Mathew Marquis
Posted on:
July 9, 2015
“Championing responsive web standards” is the primary goal of the Responsive Issues Community Group, and it continues to be—we put it right there in the name, after all. But our secondary goal—paving a new way for designers and developers to participate in web standards—has been tough to balance at the same time.
By taking point on the issues that matter to the community and encouraging designers and developers to come to us with their ideas, I’ve worried that we’re putting ourselves in a position to someday play unwitting web standards gatekeepers. I’ve worried that web standards will still be thought of as a problem solved elsewhere, by those with the right connections and influence to get them solved—not the responsibility of each and every one of us.
I’ve worried that the RICG could someday become the new old guard.
I’ve been unsure of the way forward, though—in fact, I’ve been dragging my feet a little. I have
a spec
to work on, but I really haven’t; I haven’t even been sure about having my name on it. I don’t want to
own
it. I want
everyone
to own it. That’s what I want web standards to be.
But the RICG’s strength is that it’s made up of hundreds of brilliant developers and designers, and they’re smarter than I am. For all my worrying, I should have realized that there was already a plan for the works.
Enter the WICG
The brand new
Web Incubator Community Group
—chaired by the RICG’s own
Yoav Weiss
and
Marcos Caceres
and Google’s
Chris Wilson
—aims to “make it as easy as possible for developers to propose new platform features, in the spirit of the
Extensible Web Manifesto
.” Their goal is to take the lessons learned during the RICG’s responsive images slog and adapt web standards to match. No more being shoehorned into ancient mailing lists and IRC channels—unless that’s what you want to use, of course.
They won’t act as gatekeepers; they won’t thumbs-up or thumbs-down your proposals. They
will
guide you through the web standards process, and they’ll use all their experience to make it go as smoothly as possible.
As for the RICG, we’re not going anywhere. We’ve got work to do; we’ve got a platform and a purpose, and we’re going to keep on picking the web standards fights that need to be fought. We’ll keep on encouraging people to get involved in web standards, for certain, but now we can do so with
direction
. You don’t have to join our IRC channel or pipe up on our mailing list. We’ll get you set up with our friends at the WICG, and they’ll help you get started—maybe that’ll lead you back to us, and maybe it’ll lead to your own community group and your own specification. If you do end up with us, rest assured that we’ll be learning all the same lessons as the WICG: we’ll find new ways to meet you where you’re most comfortable, instead of trying to make you stick to our processes.
The RICG and the WICG share more than a few letters and a handful of members. We share the same goal:
to create a welcoming and inclusive environment for anyone that wants to get involved in web standards
. They not only have the RICG’s full support, but they have us completely on board. We’ll be publishing our specifications through the WICG from here on, backed up with all the patent protection of the W3C. No more pirate radio web standards.
We made a lot of our progress by bucking the rules in the past, because the rules weren’t what they should have been. But the RICG—and now the WICG—aim to make new rules for the web standards game, and it wouldn’t be fair if we put ourselves outside of them at the same time. By aligning the RICG with the WICG, we’re ensuring that we play on the same field as every other group of developers with a good idea.
That’s the way it should be.
RICG Newsletter
Mathew Marquis
Posted on:
April 14, 2014
Since our Chair is so lousy at posting updates to our mailing list,
Eric Portis
—author of this
incredibly helpful article on the
sizes
srcset
syntax
—is going to be helping out! We’ll be posting something every other Friday—short general-purpose posts on using `picture` and `srcset` in your projects or a few helpful links, along with brief announcements and progress updates on the implementations that are already underway.
If you’re not an official member of the community group—and you should
definitely
join the CG
—you can receive these same updates by subscribing at
responsiveimages.org
The Big Web Show, episode 112 “Responsive Images Get Real”
Coralie Mercier
Posted on:
February 25, 2014
Mat Marquis was on
The Big Web Show, episode 112 “Responsive Images Get Real”
, published today.
Quoting from the podcast page:
Mat Marquis, chair of the W3C Responsive Images Community Group, sits down with Zeldman to discuss guidelines for responsive images in multi-device design. The two web designers discuss the history, theory, and multi-leveled challenge of responsive images, the path to standardization, and what browsers will do next.
The goal of a “responsive images” solution is to deliver images optimized for the end user’s context, rather than serving the largest potentially necessary image to everyone. Unfortunately, this hasn’t been quite so simple in practice as it is in theory.
Interesting Responsive Images workaround
Tady Walsh
Posted on:
October 16, 2013
A colleague of mine, Ian Devlin, put this up yesterday. I’ve had a small play with it and forked it to add some caching. It seems like a pretty good workaround (note, I don’t say solution!).
I’m sure he’d be glad of some community feedback on it. I haven’t really had the time to poke holes in it fully yet, but I like what it does. His article explains in depth what he is doing but in synopsis, he is creating the img source from a php script which can also take arguments for height, width, crop and scale. Tied in with Scott Jehl’s picturefill script, it works very dynamically and seems very responsive.
All thoughts and comments greatly appreciated.
Reasoning behind srcN replacing srcset and picture
Marcos Caceres
Posted on:
October 14, 2013
This post was written by John Mellor. Reposted here from our mailing list for easier sharing.
By now most of you will have seen and
started discussing
the alternative markup proposal Tab and I came up with, intended to replace both srcset and .
Tab’s spec write-up gives great examples of how this solves the various use cases; but I think we owe you an explanation of why srcset, , or some other simpler approach can’t solve the same use cases. Let me try to explain, and also preemptively answer some questions.
You’re all familiar with the 3 main
use cases
for responsive images: devicePixelRatio based resolution switching, viewport size based resolution switching, and art direction.
The key difference between viewport-based switching and art direction is that in the viewport case a bandwidth-constrained browser should be allowed to download a lower resolution version, whereas in the art direction case it’s essential that the browser strictly obey the switch, as the images may have different aspect ratios, and downloading the wrong one could break the layout.
The simple srcset syntax that WebKit recently implemented handles dpr-based switching, but neither of the other cases. The extended srcset syntax with ‘w’ and ‘h’ attempts to handle viewport-based switching, but makes no attempt to solve art direction – and in fact, it doesn’t successfully solve viewport-based switching either, for rather subtle reasons. Consider a page with a simple 1-3 column responsive grid:
.grid-column { width: 100%; }
@media (min-width: 640px) {
.grid-column { width: 50%; }
@media (min-width: 960px) {
.grid-column { width: 33%; }
If this grid contains images that are 100% of the width of their column, then smaller viewport sizes sometimes lead to larger images than large viewport sizes. Paul Robert Lloyd has a great illustration of this in his
2012 post
I plotted the required image width at a range of viewport widths:
Notice how the widest image is required at a 639px wide viewport, and on wider devices smaller images are used. This is why srcset isn’t good enough for viewport-based switching. If a bandwidth-constrained browser chooses to download an image destined for narrower viewports, it might actually end up downloading a larger image file!
So what about the element? handles dpr-based switching and art direction well, but isn’t suitable for viewport-based switching, as the browser isn’t allowed to download images destined for smaller screens, even if they are in fact just different resolutions of the same image, since it has no way to know this. You can sort of support viewport-based switching if you create a lot of artificial breakpoints at different viewport widths, and provide a 0.5x, 1x, 2x and 3x image (the 0.5x image being for bandwidth constrained devices) at each; but that generally means you have to repeat every image url 4+ times, which simply isn’t practical. In addition, working out what breakpoints to use for viewport-based switching is very laborious and confusing. For the responsive grid case above, you’d have to encode it as something like:


srcset="160.jpg 0.44x, 320.jpg 0.89x, 480.jpg 1.33x, 640.jpg 1.78x, 960.jpg 2.67x">
srcset="160.jpg 0.35x, 320.jpg 0.7x, 480.jpg 1.04x, 640.jpg 1.39x, 960.jpg 2.09x, 1280.jpg 2.78x">
srcset="320.jpg 0.55x, 480.jpg 0.83x, 640.jpg 1.1x, 960.jpg 1.66x, 1280 2.2x, 1920 3.31x">

srcset="160.jpg 0.44x, 320.jpg 0.89x, 480.jpg 1.33x, 640.jpg 1.78x, 960.jpg 2.67x">
srcset="160.jpg 0.36x, 320.jpg 0.73x, 480.jpg 1.09x, 640.jpg 1.45x, 960.jpg 2.18x, 1280.jpg 2.91x">

srcset="160.jpg 0.44x, 320.jpg 0.89x, 480.jpg 1.33x, 640.jpg 1.78x, 960.jpg 2.67x">
srcset="160.jpg 0.36x, 320.jpg 0.73x, 480.jpg 1.09x, 640.jpg 1.45x, 960.jpg 2.18x, 1280.jpg 2.91x">
srcset="320.jpg 0.57x, 480.jpg 0.86x, 640.jpg 1.14x, 960.jpg 1.71x, 1280 2.29x, 1920 3.43x">


That’s pretty hard to read, let alone write. Notice how each image url gets repeated up to 9 times here! And in order to reuse the same set of images at the various breakpoints, I had to get out a calculator to work out all the x multipliers 🙁 It could be made slightly simpler if you’re willing to make larger jumps in viewport width, but that has the downside that users will download more unnecessary data. Ultimately, the problem is that the web developer needs to encode that graph I plotted above into the , but they are forced to approximate the lines by plotting a series of points, whereas it would be much easier if there was a “straight line” primitive.
Instead with the srcN proposal, this becomes way simpler:

That first part might look a little bit cryptic at first, but if you compare it to the breakpoints in the grid media queries above you’ll see how it’s actually a pretty intuitive way of expressing the column widths above. Remember that this is for the tricky case of a responsive grid; for simpler cases like a full width header image you just put “100%” (i.e. the graph is a single straight line), whereas with srcset or you’d still have been stuck giving 7+ points along the line.
And then you simply list the pixel widths of the available images, which is much easier than having to do a bunch of maths to link each image to a variety of viewport widths and devicePixelRatios; crucially you never have to repeat each image!
srcN also covers art direction by allowing you to select which set of images you want using -style media queries, but these should be used only for art direction, not for viewport switching (which is covered by the mechanism above).
FAQ
Q) This seems to focus on flexible-width images (e.g. width: 100%). What about fixed-width images?
A) For fixed-width images, srcN lets you use the familiar “s.jpg 1x, l.jpg 2x” syntax that srcset had, as for fixed-width images that works fine. If you prefer, you can also use the new syntax with a fixed width instead of a percentage width, in the form “320; s.jpg 320, l.jpg 640”, but that’s more verbose, so it only really makes sense to use that in cases where an image is sometimes flexible and sometimes fixed width, for example if you have a max-width in px set on an image whose width is set in %.
Q) Does this fully obsolete srcset and ?
A) Yes, this completely replaces all functionality of both of those. Ideally, browsers that have already implemented the basic srcset syntax would remove that as soon as possible before sites start to depend on it (but if not it would be possible for such browsers
to integrate srcset
, just like src acts as a fallback).
Q) Why src1, src2, etc instead of child source elements like has?
A) Some implementors complained that having child elements is one of the things they regret about

Picture Element Example