W3C Publishes First Draft of HTML Responsive Images Extension

The web needs a more intelligent way to serve images; one-size-fits-all doesn’t work in an increasingly mobile world.

Web developers need a way to specify images based on screen size, bandwidth and other factors. To help them do that the W3C, the group that oversees the HTML standard, has published the first editor’s draft of the HTML Responsive Images Extension. The proposal is just a draft, but it points to one possible solution for the responsive image conundrum.

The problem is this: No one wants to waste bandwidth sending large images over limited mobile pipes, but everyone wants images to look good on the myriad screens connecting to today’s web. Developers need to send small images to small screens and large images to large ones. Currently, web authors use a variety of hacks to (incompletely) work around the problem, but to really solve it the web needs new tools.

The new proposed Responsive Images Extension is hoping to be that new tool. The proposal is one of the first community-created specs, coming from the work of the Responsive Images Community Group. The spec is edited by developer Mat Marquis, who represents the Community Group, and Microsoft W3C member Adrian Bateman.

The draft seeks to find a middle ground between the WHATWG’s proposed srcset attribute for the img tag and what many web developers want — a new <picture> element.

The goal for developers is to have a simple, but backward-compatible way to serve images based on screen pixel dimensions, density, user zooming and bandwidth. For the latter image choice would be left up to the browser.

In addition to those basic requirements, the Responsive Image Extension proposal has other goals:

  • Fallback gracefully on older user agents
  • Can be polyfilled effectively
  • Retains, at a minimum, the same level of accessibility as current img element
  • Preserves separation of content markup and styling
  • Provides a purely client-side solution that can include JavaScript, but doesn’t require it
  • Supports use cases where authors need to explicitly define different image versions as opposed to simply different resolutions of the same image
  • Provides a consistent and predictable pattern for delivering alternate media sources based on client context
  • Supports succinct but understandable mark-up

Put it all together and clearly the HTML Responsive Images Extension has its work cut out for it. Here’s some sample code showing how the proposed picture element might handle all that:

<picture alt="">
    <source media="(min-width: 45em)" srcset="large-1.jpg 1x, large-2.jpg 2x">
    <source media="(min-width: 18em)" srcset="med-1.jpg 1x, med-2.jpg 2x">
    <source srcset="small-1.jpg 1x, small-2.jpg 2x"> 
    <img src="small-1.jpg"> 
</picture>

The first line contains a media query aimed at large screens and the uses the srcset attribute to specify two images, one for standard resolution displays and one for high-DPI screens. The second line handles medium size screens, while the third handles smaller screens and serves as the fallback for low-bandwidth situations. The last line uses the standard img tag for older browsers.

It’s a mouthful of markup, but it’s similar to how the HTML5 <audio> and <video> tags work. Unfortunately it’s sufficiently different enough to be confusing. As Philip Jagenstadt of Opera Software notes, “personally, I don’t think it’s a good idea to reuse the syntax of <video> + <source>, since it invites people to think that they work the same when they in fact are very different.” He goes on to add that “this is neither a “yay” nor “nay” from Opera Software, just my POV from working on HTMLMediaElement.”

And therein lies one big problem for the HTML Responsive Images Extension — browsers aren’t on board with it just yet.

For now that’s fine, the draft is, at this stage, just a proposal in search of feedback. If all goes well browser makers will now step into the fray to enumerate their concerns and any potential pitfalls on the implementation side. And there are pitfalls, including potential conflicts with browsers’ “look-ahead” parsers, but hopefully over time those will be worked out.

If you’ve got ideas on how to improve <picture>, head over to the Responsive Images Community Group and let them know what you think.