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.