Responsive Images and the Tyranny of Web Standards

If you follow HTML5 and web standards conversations online via twitter or popular blogs like HTML5 Doctor, you’re no doubt aware of some of the recent developer interest around “Responsive Images.” You’re probably also aware of the recent hullabaloo over the rapid steps that the WHATWG took to include the srcset <img> attribute proposal in the HTML living standard, over a counter-proposed <picture> element that was popular with developers.

I’ve followed many of these discussions myself, and while I’m quite excited that we’re finally getting down to brass tacks with a responsive image solution, the drama that is playing out between developers, browser implementers, the W3C and the WHATWG has reminded me of the false sense of security web standards provide to us developers.

The truth is this: web standards are often a tyranny to developers and designers alike. By themselves, they constrain just as much as they free, and they are designed not for our benefit, but primarily for the benefit of platforms and software on which our solutions run. Embrace them we should, but never in isolation, and never with a complete reliance on the standards process and manna from browser implementers. Instead, we should approach web standards with an additive mindset: keenly aware of where the process doesn’t yet serve our needs and filling in those gaps with strategies, solutions and libraries that help us do what we do best, which is deliver excellent experiences for our customers.

The Backstory

Back in 2010–in fact, exactly two years ago tomorrow–web guru Ethan Marcotte coined the term “Responsive Web Design” in a seminal article of the same name for A List Apart. RWD, as it has come to be known, is made of up three design tenets:

1. Media Queries
2. Fluid Grids
3. Flexible Images

For the third tenet, Marcotte pointed to an article on his own blog, in which he discussed some CSS- and JavaScript-based strategies for scaling images up or down based on the current viewport or window size of the browser. While variations in form surfaced, for a time, “fluid” meant scaling up or down.

Over the last few years, Media Queries have become an HTML5 darling, and CSS Grid systems have flourished in their own right, but for that third tenet, flexible images? Well, let’s just say that things have been rocky.

To begin with, Marcotte’s solution is a valid one, but a few years of experimentation with RWD revealed some problems with the strategy of auto-scaling images based on the viewport.

To explain what I mean, consider this example: I have a collection of images on my page, and each is about 800k in size. They are high-fidelity images, and they look great on a desktop browser at 1920x1200.

Now let’s say that I want to get into RWD, and plan to resize those images down to around 200x125 for mobile devices. By using the classical “fluid images” approach, I’d get some good-looking, smaller images, but with one problem: they’d still be 800k each, when at 200x125, 80k would do just fine. These are things we may not worry about much in a desktop world anymore, but bandwidth still matters in mobile, and sending images 10x larger than needed is not a tenable solution.

As it turns out, we developers discovered that it wasn’t “fluid images” we needed after all, but “responsive images.”

The <picture> Proposal

By “responsive,” we mean to say that images have some level of conditional inclusion logic like that enabled by media queries. Over the last few years, several alternative solutions, both server and client-based, have been explored, debated and finally, discarded, as the flaws, hacks and workarounds of each became apparent.

Every attempt at solving this problem was laced with a general consensus that what developers really needed was something “official” from the browsers. In that vein, in December of 2011, Bruce Lawson proposed a strawman, media query-aware '<picture>'

<picture alt="cool-image">
    <source src=hires.png media="max-width:1920px">
    <source src=midres.png media="min-width:800px">
    <source src=lores.png>
    <!-- fallback for browsers without support -->
    <img src=midres.png alt="cool-image">
</picture>

The beauty of this element is not only its clear semantics, but its functional precedent in the HTML5 <video> element, which currently offers the same media attribute support, and across all browsers, at that.

It’s here that things get murky, and I’m not going to recount any of the “who said what,” “who proposed which” or “what Hixie was wearing the day he wrote this post” here, because others have done a fine job of that already (See Bruce’s summary, as well as a great summary/op-ed from Jeremy Keith). It’s also not relevant to this story.

What is relevant is that <picture> got a lot of developer interest quickly, leading to the formation of the “Responsive Images Community Group” at the W3C in February. A lot of smart people got involved and began to discuss <picture>, its potential and limitations, with the expectation that they were working towards a solution to present to the W3C HTML5 Working Group[1].

Only, that’s not what happened, exactly.

The Drafted Solution and the Ensuing Fallout

What did happen is that, in mid-May (just over a week ago at the time of this post), an alternative responsive images proposal was added to the HTML Living Standard maintained by the WHATWG. As opposed to relying on a new element and media queries, this one, from an Apple representative, utilized a new srcset attribute on the <img> tag:

<img src="cool-800-600-at-1.jpeg" alt="cool-image"
     srcset="cool-1920-1200-at-2.jpeg 1920w 1200h 2x,
             cool-1024-768-at-1.jpeg 1024w 768h 1x,
             cool-icon.png 200w 200h">

Needless to say, many developers were nonplussed by this proposal. I think the best summary of developer sentiment came from Remy Sharp himself.

There’s no question that the syntax here leaves much to be desired. <picture> isn’t perfect, but many felt it was a fine starting point due to its semantics and similarity to existing capabilities in <video>. But these things can–and will–be easily debated, hashed-over and addressed in the WHATWG’s mailing list, which is open–even if the decision process is not–so I have no doubt that the final specified solution won’t look as gnarly as the example above.

My bigger concern is the process by which developers came together around a good idea and attempted to drive it forward, only to see their efforts ignored in favor of a proposal delivered by a browser representative. Putting it another way: in the case of web authors (that’s us developers) versus browser implementers (that’s Apple, Google, Microsoft, Mozilla and Opera), judge Hixie and the WHATWG ruled in favor of the implementers.

In fairness, I’ll admit I’m generalizing, and Jeremy’s post does do a good job of fleshing out the story quite a bit. If you read that piece, as well as others I’ve linked to in this article, you’ll discover that <picture> is no savior of responsive images. It’s verbose, slow-performing and the <video> precedent argument is considered flawed, as browser implementers have apparently had quite a time dealing with the media rules on that particular element.

So I recognize that, in the context of the <picture> vs srcset battle royale, we’re all winners because a solution is on its way. But I also believe that this entire drama has revealed a dirty little secret: that the web standards process is one that invites participation from developers, but ultimately places its thumb on the scale in favor of browser implementers.

The Bottom Line and What you Can Do

So what is there to take from all of this? Is the HTML5 honeymoon over? Hardly. Make no mistake, things are not all doom and gloom. HTML5 is awesome, and, as developers, we owe the WHATWG, the W3C and the browsers themselves a heap of thanks for making the web the cutting edge place to be.

But in spite of all of this, the existence of a seemingly rapid and inclusive standards process should not lull us into a false sense of security. I believe that this recent responsive images drama–along with the vendor prefixes drama of April–serves as a reminder of that truth. As web developers and designers, we have been pushing and pulling at the standards process–while never relying upon it to solve all of our problems–for nearly two decades, and we should continue to do so now more than ever.

So what does that mean for you, the intrepid web developer? It means that this is your web, too. You own the most important part: the assembly of specs and standards and browser capabilities into elegant and functional solutions for your users. And as an owner, you have a role to play, which might mean one, a few or all of these things:

1. Get involved - Join W3C Community groups that interest you, like Responsive Images or Core Mobility; Join the WHATWG mailing list and, if you have something to say, share it!
2. Keep pushing - Push for more clarity from the W3C on the role that Community Groups play in the standardization process; If you have a passion for a competing implementation to an in-process standard, blog, tweet and yell about it until you get somebody’s attention.
3. Mind the gaps - HTML5 has gaps, or pieces of the various specifications that either don’t work consistently, or leave something to be desired (I’m looking at you appCache, Forms and IndexedDB, to name a few). As you learn and adopt HTML5 for your own applications, pay attention to those implementations that promise more than they might deliver, and respond accordingly.
4. Fill the gaps - For those technologies that are incomplete, pay attention to the myriad of great tools and libraries available that can help you deliver on the promise of HTML5. This could be as simple as a polyfill for Local Storage, or as robust as using Kendo UI for cross-browser touch support in your UI elements. Whatever it is, there’s a whole world of tools that can help you pick up where the standards process and the browser vendors leave off.

Of course, this list is just a start, and your involvement may look markedly different than mine. As I write this, I’m even reminded that I could do more of these things myself, and those I already do, I could improve.

The bottom line is this: web standards are a key piece of the open web puzzle, but so is every single one of us. We, fearless developers and designers, are the balance of that puzzle. We push the process, pull at the browsers, adopt the features and, above all else, deliver the web that the rest of the world uses every day.

So let’s keep pushing together.

Resources

• Original “Responsive Web Design” Article
• Bruce Lawson’s <picture> Element Proposal
• Responsive Images Community Group
• HTML Living Standard srcset Proposal
• Jeremy Keith’s Summary Post
• Bruce Lawson’s Summary Post

[1] It’s important to note that W3C Working Groups, which consist of representatives from full W3C member companies like Microsoft, Mozilla, Google, Apple and Adobe, are a wholly different entity than W3C Community Groups, which are open to everyone, but do not play an official role in the standards process. In the spirit of full disclosure, it’s probably also important to note that Telerik is a member of the W3C Community, and that several members of the Kendo UI team (including myself) are members of various W3C Community groups (including the Responsive Images Community Group).