This story was written by Keith Dawson for UBM DeusM’s community Web site Develop in the Cloud, sponsored by AT&T. It is archived here for informational purposes only because the Develop in the Cloud site is no more. This material is Copyright 2012 by UBM DeusM.

Getting to Responsive Images

Making images behave right in responsive designs is hard to specify and hard to implement.

Web developers and browser implementors are working separately but coming to mutual understanding on a specification for responsive images.

We have recently discussed responsive design, which is high up on the list of current issues in Web development. And we have talked over the problems in Web design, development, and rendering that arrived with the advent of Apple's ultra-high-resolution "Retina" displays. These issues come together in the problem of handling images optimally in an environment in which visitors come to Websites with devices offering a wide range of screen sizes and pixel densities.

For more than a year, Web developers have been wrestling with the issue of how to get Web clients and servers to do the right thing with images no matter what device a Website visitor is using. Writing for A List Apart last January, Mat Marquis (@wilto) described some of the early approaches -- it would not be inaccurate to call them "hacks" -- that were tried in order to give a Web server enough information to select the proper image to serve, before the browser had started laying out a page. He ended up concluding that the current tools were insufficient to get the job done, and sketched out the beginnings of a new markup pattern that might do it, based on the <audio> and <video> tags and using the syntax of established media queries.

Soon Marquis had pulled together a Responsive Image Community Group of developers, working under the auspices of the W3C, to flesh out a specification for what became the <picture> element. By May of this year, however, the RICG had come up against the reality of how little plugged-in such W3C community groups actually were with other parts of the work of evolving the HTML standard. The browser makers, through the mechanism of the WHATWG, had been working on the same problem and had come up with a different solution. A very different solution. In a followup article on A List Apart, Marquis characterized Web developers' reaction to the syntax of the WHATWG's img@srcset proposal: "At best unfamiliar, and at worst completely indecipherable."

Soon thereafter, Jason Grigsby identified the philosophical gulf separating the thinking of the browser makers and the Web developers on the subject of how to describe responsive images: "If the [browser] lookahead pre-parser is the tourist with a detailed itinerary of places to visit, [the developer's] responsive images are the go-with-flow tourist waiting to see what things look like before choosing what to do."

Progress has been made over the summer. The two groups are talking. Draft specs exist at the W3C for both the RICG's <picture> proposal and the WHATWG's img@srcset proposal. The former now incorporates the latter as a kind of shorthand specification for simple cases. Marquis has posted a progress report on The State of the Picture Specification, and he is hopeful on the possibility of Web developers having a seat at the specification table going forward.

It's a hard problem to give a developer tools to describe how images should behave in a responsive design. It's another hard problem to figure out how a browser can best deliver the desired results. With luck and hard work we'll end up with something in the HTML spec and in browsers that makes this all happen in a graceful way.

You can keep up with developments in this area by following the Twitter account Mat Marquis set up for the purpose: @respimg.