BT

New Early adopter or innovator? InfoQ has been working on some new features for you. Learn more

Round-up on Responsive Images for the Web

| by Dio Synodinos Follow 1 Followers on Aug 16, 2013. Estimated reading time: 2 minutes |

Nightly build of WebKit now supports the W3C srcset attribute spec on image elements, allowing developers to specify higher-quality images for your users who have high-res displays, without penalizing the users who don’t. It also provides a graceful fallback for browsers that don’t yet support the feature:

<img alt="My breakfast"          
	src="breakfast.jpeg"          
	srcset="breakfast-HD.jpeg 2x, breakfast-phone.jpeg 100w, breakfast-phone-HD.jpeg 100w 2x">

WebKit was already supporting the -webkit-image-set CSS function for a while, which is very similar to srcset, and is used to lets CSS properties that take images provide a list of candidate image urls, each with a modifier such as “2x”. This allows the browser to choose the best image for the user’s device:

body {     
	background: -webkit-image-set( url('path/to/image') 1x, url('path/to/high-res-image') 2x ); 
}

This move by WebKit comes at a time when the community and browser implementor are still split between what the best choice for responsive images on the web. In a few weeks the Responsive Images Community Group (RICG) will be getting together in Paris to discuss a path forward for responsive images. In his call for the meeting, RICG’s Yoav Weiss outlines the potential future solutions and the current developer practices:

For the last couple of years, various folks have been working towards finding a way to bring  responsive images to the Web, with significant interest from Web developers. Although we now have 3 proposals on the table (srcset [1], <picture> [2] and client-hints [3]), we've had trouble getting sufficient momentum behind browser implementations that would let the market decide which solutions fulfill the use cases most effectively.

In the mean time, Web developers have had to make due with custom polyfills which often prevent browsers from loading the image resources until after the DOM was (at least partially) loaded and Javascript on the page has run. This directly hinders the performance work browser engineers have done over the years to optimize resource loading, and get requests on the wire as soon as possible, according to their priority. That leaves developers with the dilemma "Do we stall the image load, or download unnecessary image data which will slow down the overall load time and inflate the user's bills?"

Current popular solutions for the challenges of bringing responsive images on the web, include:

  • Picturefill: A polyfill which mimics the proposed <picture> element,
  • HiSRC: A jQuery plugin which at page load time chooses to download (or not) a high-res version depending on if there is device support, and
  • Adaptive Images: A server-side solution for serving the right image resolution/size.

Rate this Article

Adoption Stage
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread
Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Discuss

Login to InfoQ to interact with what matters most to you.


Recover your password...

Follow

Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.

Like

More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.

Notifications

Stay up-to-date

Set up your notifications and don't miss out on content that matters to you

BT