Responsive Image Chaos

TL;DR: This is just a recap of what’s happening now. If you are up to speed as of today, you can just skip to my brief opinion.

Background

As I mentioned in my post iPad Retina Display Concerns and Tips, even Apple, with over a year of the Retina Display on the market, had not devised a method to detect pixel density and serve appropriate images. Visiting Apple’s site on an iPad 3 first gets you all the regular resolution images, and then (after some UA sniffing) pulls down the high resolution images. This is generally regarded as a bad idea, especially considering people who have bandwidth caps and fees.

The W3C spun up the Responsive Images Community Group in February (I am a member, but fell off after the JPEG 2000 discussion) hoping to get feedback from developers on updates to HTML that would allow for multiple assets to be specified. Ideally, a browser will see all the assets and choose the best fit, preventing redundant downloads. One of the goals was to define a change to HTML that would still keep it backward compatible for older browsers, unsupporting browsers, and browser add-ons (such as accessibility tools).

This was happening in parallel with WHATWG, the other standards body working on HTML. WHATWG, however, seemed to be unaware of the Responsive Images Community Group and the discussions going on over there. Event though WHATWG now has its own W3C Community Group, its purpose is for patent coverage under W3C and WHATWG members are not actively participating, let alone wandering through to see what other W3C Community Groups exist (WHATWG as W3C Community Group in Name Only).

Happening Now

WHATWG has released its own proposal (added to the HTML draft specification) for addressing adaptive images and it appears to have taken nothing from the work being done in the W3C Responsive Images Community Group. Given the bitterness among web developers toward the WHATWG process it is no surprise that there has been an eruption of anger, frustration, and revisiting old issues. I think this tweet sums it up nicely:

full circle: WHATWG formed to counter hegomony of W3C, now W3C is the counter to hegemony of WHATWG timkadlec.com/2012/05/wtfwg/

— Steve Faulkner (@stevefaulkner) May 16, 2012

People far closer to the issues than I (and far smarter, oddly) have weighed in on this. I don’t care to recap it all here because it requires far too much detail and back-story. Instead I have cultivated some posts you can (and maybe should) read to give you the technical breakdown and the process breakdown (see how I am using “breakdown” in two different ways there? not yet? you will):

Feedback from the Community

WTFWG by Tim Kadlec:

The developer community did everything asked of them. They followed procedure, they thoroughly discussed the options available. They were careful enough to consider what to do for browsers that wouldn’t support the element—a working polyfill is readily available. Their solution even emulates the existing standardized audio and video elements. […] Meanwhile an Apple representative writes one email about a new attribute that only partially solves the problem and the 5 days later it’s in the spec.

Secret src by Jeremy Keith:

But let’s be clear: this is exactly how the WHATWG is supposed to work. Use-cases are evaluated and whatever Hixie thinks is best solution gets put in the spec, regardless of how popular or unpopular it is.

Responsive Images and Web Standards at the Turning Point by Mat Marquis:

Participants in the WHATWG have stated on the public mailing list and via the #WHATWG IRC channel that browser representatives prefer the img set pattern[;] […] they understand the browser side better than anyone.

On the other hand, the web developer community has strongly advocated for the picture markup pattern. Many developers familiar with this subject have stated—in no uncertain terms that the img set syntax is at best unfamiliar—and at worst completely indecipherable.

From a post at the W3C Responsive Images Community Group by Kevin Suttle:

The more I think about this, the more I think that this isn’t our problem to solve. It’s really a browser and server problem.

Media Queries Can’t Be Used for Resolution Negotiation by Tab Atkins:

You simply can’t make a good decision about which resolution to send to the user based on information from Media Queries. It’s fundamentally a hard decision based on information that’s difficult to expose in a reasonable manner.

HTML5 adaptive images: end of round one by Bruce Lawson:

[A]s it exists in the current, first draft of the spec, the syntax is revolting:

<img src="face-600-200-at-1.jpeg" alt=""
     srcset="face-600-200-at-1.jpeg 600w 200h 1x,
             face-600-200-at-2.jpeg 600w 200h 2x,
             face-icon.png 200w 200h">

Of course, this can be improved, and must be. This isn’t just about aesthetics. If the syntax is too weird, it will be used wrongly.

I found another tweet (who doesn’t like 140 character summations?) that I think captures the gist of the concern with the WHATWG proposal:

img@srcset added to draft. Good to see authors have /another/ microsyntax to learn. It’s not like they had any trouble with vendor-prefixes.

— Remy Sharp (@rem) May 15, 2012

My Take on This

I don’t care for the WHATWG proposal. I think it’s a cumbersome mess with too many places for errors (typos) that a developer won’t see without a lot of extra work.

I am happy, however, that there is finally movement. Even movement in the wrong direction can be good in the long term as long as the folks who’ve blown up about it the last few days can have an impact.

I also don’t believe this is anywhere near over (also good). In the WHATWG IRC chat from yesterday, Hixie was open to the idea of writing an article for A List Apart. The suggestion for the piece would be to cover how people can get involved, though I suspect it will tackle some of the technical issues people have with the WHATWG proposal.

Even if it all falls apart, web developers have the power to change the spec by just using what they prefer coupled with polyfills. Since the HTML specification is ultimately intended to reflect what is happening in the wild, it may just catch up. After all, that’s the tactic we have used with time.

Update: May 17, 2012

• The Unbearable Lightness of HTML5 – or, the priority of constituencies versus the great dictator by Jeffrey Zeldman.