Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Save Bandwidth, Be Responsive! The New Responsive Images Community Group at W3C

DZone's Guide to

Save Bandwidth, Be Responsive! The New Responsive Images Community Group at W3C

· Web Dev Zone
Free Resource

Tips, tricks and tools for creating your own data-driven app, brought to you in partnership with Qlik.

Earlier this month a post appeared on the whatwg discussion list, proposing a pie-in-the-sky-ish modification to (presumably HTTP, or maybe SPDY) standards: 'let browsers report device capabilities in a request header'.

Right, makes sense, the light-bulbs go off: why download the high-res image at all, when the client viewport is only 480 pixels wide?

Responsive design with CSS and JavaScript only controls the client, of course, so the server still needs to spit out way more data than the client can ever display. And then the JavaScript says, 'No, do not display this data. Display that data instead.' But both requests still went through, and both files were still streamed from the webserver to the client.

Massive waste, observed the original post. And the proposal was simple, but touched off a huge, passionate discussion -- roughly divided into the 'Sweet, that would save SO much bandwidth, and so many client-side cycles!' and 'No, adding info to the HTTP request header is pretty much always a bad idea: remember Accept-Charset?'

Then Mathew Marquis jumped in with an 'I'm late to the conversation' and steered the conversation toward responsive images, a clever, HTML5-media-inspired idea that never quite got off the ground -- until this week.

Thanks to this conversation, a new Community Group sprung up at W3C: the Responsive Images Community Group, whose homepage asserts:

Our goal is a markup-based means of delivering alternate image sources based on device capabilities, to prevent wasted bandwidth and optimize display for both screen and print.


Mathew Marquis was selected to chair the group, and quickly wrote a great summary of the discussion. Web developers will love his emphasis on usability, with a proposed markup like this:

<picture alt="Alt tag should accurately describe the image represented by all sources, though cropping and zooming may differ.">
<source src="mobile.jpg" /> <!-- Matches by default. --> 
<source src="high-res.jpg" media="min-width: 800px" /> <!-- Overrides the previous source over 800px before any assets are fetched, resulting in a single request. --> 
<img src="mobile.jpg" /> <!-- Fallback content, in the event the <picture> tag is completely unsupported by the user’s browser. --> </picture>

Turns out this idea has been percolating on and off for some time (explains Mathew). But now there's a Community Group, and now even a sample implementation -- polyfill for a feature that doesn't yet exist!

If you're a web developer interested in responsive design, and want something more powerful and less wasteful than current options, then seriously consider contributing to the Community Group discussion. This is an opportunity to do something really cool for the web, something that could really benefit web developers (not to mention infrastructure engineers!) for years to come.

Explore data-driven apps with less coding and query writing, brought to you in partnership with Qlik.

Topics:

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}