The idea of “Responsive images” is that a website / web application displays the smallest image for the device that gets the best result.
That has been quite a challenge now that we have screens with Diagonal sizes measuring from an iPhone 3.5″ to a Android Nexus 5 4.7″ to iPads and other tables with 9.7″ to laptops (11″ to 17″) to Desktop Monitors (22″ to 33″) to Xbox’s and PS4’s driving HD TV’s (33″ to 60″+ ).
And you can double the issue given that some of these screens have different screen pixel densities : low-res or high-res like Apple’s Retina displays, or HDTV or 4k (aka UHDTV)
An additional challenge is the bandwidth is always pervious on a mobile device, particularly when not on Wifi, but even when bandwidth is not expensive the user does want to wait the first time to download a big image.
So downloading a 1024 px wide image for a phone or small tablet is bad, but so is using a low-res for a retina display device.
There is also a need for art direction, in that when looking at an image on a smaller screen it is nice to be able to focus on the subject of the image rather than then the setting.
Responsive Images: How they Almost Worked and What We Need on A List Apart documents their learning.
As more and more real world experience has built up over the the last couple of years, there has been some proposals to modify the HTML5 spec to do something reasonable. Basicly nerd fights over the last 2 years 🙁
Out of that 2 things are starting to emerge :
1) One is an additional “srcset” attribute to the existing IMG html tag.
“srcset” will let Web developers provide multiple resources in varying resolutions for a single image. The browser can then pick the resource that matches the device’s pixel ratio capabilities.
and the “old” attribute “src” will handle older browsers with a fallback.
it can be used in a IMG html tag
<img alt="My fancy picture"
srcset="banner.jpeg 1x, banner-phone-HD.jpeg 2x"/>
Browsers with two or more device pixels per CSS pixels (“retina”) get the 2x image, 1 device pixels get the “normal” image and browsers that don’t understand srcset, get “banner.jpeg” via the traditional src attribute.
In August 2013, WebKit implemented srcset, so it should be in Safari 7, see also WebKit Has Implemented srcset, And It’s A Good Thing
And as of February 2014, the beta Chrome is now supporting srcset
Note: that srcset pixel ratio is only part of the W3 srcset spec draft but its a start!
2) AND they are both (webkit and chrome) going to support the the “Picture” element, which is similar looking to the “video” and “audio” elements, and is intended to be used to point at a image source based on media queries.
<source media="(min-width: 64em)" srcset="wide-image.jpg 1x wide-image-HD.jpg 2x"/>
<source media="(min-width: 37.5em)" srcset="med-image.jpg 1x med-image-HD.jpg 2x"/>
<source srcset="narrow-image.jpg 1x narrow-image-HD.jpg 2x"/>
<img src="narrow-image.jpg" alt="This picture loads on non-supporting browsers." srcset="narrow-image.jpg 1x, narrow-image-HD 2x"/>
Both of these new attributes and elements allow for fallbacks for older browsers even without use of polyfills which is neat, and with the use of a polyfill we can start to use these new markups and server up optimal and responsive images while bring future friendly.
One of the best places to check track of samples, use cases and implementation status about responsive images is the
Responsive Images Community Group web site.
and there is a new posting on a List a Part : A Q&A on the Picture Element
Update (April 24th) : The responsive image polyfill now supports the Picture element draft specification in its version 2 branch.
Update (May 2nd) : Jeffrey Zeldman talks with Scott Jehl (of Filament Group fame aka the Boston Globe web site) on the Big Web Show podcast about Responsive Images, Picturefill, and Web Standards with lots of links in the show notes