An Event Apart: The Future of Responsive Images

At An Event Apart in Atlanta GA 2014, Mat Marquis walked through the history of developing a responsive images solution for the Web and the solution coming to browsers soon. Here's my notes from his talk The Past, Present, and Future of Responsive Images:

Responsive Web design is made up of three things: a flexible grid, media queries, and flexible images & media. But as developers we've also made responsive design synonymous with large web sites.

One of the most common critiques against responsive Web design is that it creates large (file size) Web sites, thereby slowing Web pages down.

The average Web page sizes are 1.6MB. Images are responsible for most of these large sizes.

The Web is all about universal access. We are responsible for making sure people can get to content and not block them based on their device.

We are surrounded by high resolution displays. Larger images can be even 4x higher than a standard resolution image.

The complete works of William Shakespeare can be downloaded 3 times before reaching the files sizes of some Web sites.

72% of responsive sites send the same assets to mobile sites as they do to desktop sites.

Measure twice, cut once. Web browsers should take the burden of images on.

Working Through Options

Images and media can be made fluid by setting max-width to 100%. This requires us to send images at the largest size they can be shown.

In the video element, you can use the media attribute to send different sources to different sized screens.

The image element, however, only fetches a single element and brings it down to the screen.

To avoid downloading big images on mobile, developers loaded small images first, then replaced them using Javascript if the screen was large.

Due to more aggressive browser pre-fetching behavior, this solution stopped working. Many new solutions were tried until ultimately, a Javascript solution was ruled out.

Two competing proposals for a browser-standard to support responsive images emerged the picture element and srcset.

srcset was efficient at dealing with resolutions and worked outside of media queries. These ideas were adopted into the new picture element.

srcset is specced as a suggestion. People can set up preferences like: always give me high res image, never do, or give them when bandwidth permits.

The picture element was submitted as a proposal but browser manufacturers were not providing feedback.

A proposal from Google for srcN gained a lot of traction in a short amount of time. The basic structure was the same as picture but with a few challenges. But the syntax had issues with numbered attributes.

Most people liked the srcN proposal except for the issue of numbered attributes -which went against the way most Web standards worked.

Webkit killed srcN and srcset was removed by Mozilla. This officially took these two options off the table.

A Final Solution

After three years of work, browsers have finally agreed to support the picture element.

It is on Mozilla's roadmap for the first quarter of 2014.

Members of the Responsive Images group put in hundreds of hours to help make this happen.

This was a community effort to help the Web.

You can use the picturefill Javascript polyfill to start writing images in the picture element format.

Other Techniques

Compressive images allows you to compress images a lot at large sizes, then allow browsers to scale down to the right size.

Users saving compressive images get blurry assets if they download the compressed size image. Browser memory can be overloaded with images that are too large.

SVG images are vector-based code that scales fluidly.

SVG support is pretty great except for Android 2 and lower. So you need to provide a fallback.

Grunticon is a tool that automates all your SVG fallbacks and outputs 3 stylesheets and URIs for all support across all browsers. There's also a drag & drop solution on the Web.