Responsive Images 2013 Year-End Update
April 2020 note: Hi! Just a quick note to say that this post is pretty old, and might contain outdated advice or links. We're keeping it online, but recommend that you check newer posts to see if there's a better approach.
It can be difficult to keep track of all the ongoing “responsive images” discussion, given that it tends to take place across a number of channels, forums, and mailing lists. As you may have heard here and there, there have been three proposals for responsive images up for recent discussion: WebKit’s
srcset attribute, the RICG’s
picture element, and the
src-n pattern spearheaded by Tab Atkins.
Of the three proposals recently under discussion, two of them have been largely “removed from play” based on input from key people involved with WebKit and Mozilla over the past few weeks:
src-n: The relatively new
src-nattribute pattern proposal was rejected by members of the WebKit community due to concerns around the use of ordinal attributes (
src-2, etc.), though they weren’t alone in their objections. Most considered it to be a workable solution, though no one was particularly in love with the ordinal attributes.
srcset: The version of the
srcsetsyntax that was extended to meet all the use cases of
picturehas been rejected by the folks at Mozilla and marked as “WONTFIX” in their bugtracker.
With the two proposals above rejected—but a very real problem remaining to be solved—attention was once again focused on the remaining candidate:
A new-and-improved version of the
pictureelement that incorporates some of the more advanced features from the
src-nproposal—and should prove easier to implement in browsers—is currently being discussed in a refreshingly positive light.
The Responsive Images Community Group had planned on publishing the original
picture proposal as a “note”—meaning that it would be archived and removed from the standards track—in order to better focus on the
src-n proposal. As a result of mixed early feedback on
src-n, we opted to continue actively pursuing
picture specification with intent to simplify the proposal on the implementor side… After extensive discussion on the WHATWG mailing list, Tab Atkins and the RICG have begun work on a new
picture proposal. This new proposal simplifies how
picture can be implemented without sacrificing any authoring functionality, and incorporates some of the more advanced features of the
src-n proposal, without sacrificing any of the functionality or dramatically altering the syntax of any prior version.
(I’m trying to nickname this improved proposal “picture mk. III,” but it doesn’t seem to be sticking. I’ll keep you all posted on that front, as well.)
Here’s where some of the major players involved in the discussions stand:
Mozilla reps have seemed largely positive about the revamped
picture proposal, and plan to continue contributing to the specification. The RICG’s own Marcos Caceres is a Mozilla representative, and has put tremendous time and effort into this and previous specifications.
The Chromium team has seemed largely positive about the revamped
picture proposal. Adam Barth is waiting to review the new
picture specification when it is complete, but other representatives have reacted to the proposal favorably:
Apple representatives have seemed largely positive about the revamped
picture proposal, and are actively contributing feedback:
Interested parties from the WebKit community will likely hold off on making a formal statement until members of the Blink team have reached a conclusion (see above).
Actively contributing feedback on the updated
picture proposal. Simon Pieters in particular has helped to reshape the internals of
picture into something more implementer-friendly:
WHATWG Mailing List
Largely positive reactions to the idea of a refactored
picture spec, and no small amount of productive feedback. Kornel Lesiński has already contributed a draft of a proposed methods of simplifying
picture’s source selection algorhithm: