Webmonkey

So many screens, so few images (testing responsive sites with Adobe Shadow). Photo: Adobe.

The web needs a more intelligent way to serve images.

No one wants to waste bandwidth sending large images over limited mobile pipes, but everyone wants images to look good on the myriad screens connecting to today’s web. Currently web authors use a variety of hacks to (incompletely) work around this problem, but to really solve it the web likely needs new tools.

Unfortunately, thanks to miscommunication between standards bodies, web developers and browser makers, instead of a solution to the image problem what developers got this week feels more like a slap in the face. Eventually an adaptive image solution will likely emerge, but the real lesson for many developers will be about how the standards process works and how they fit into it, if at all.

Webmonkey has previously looked at some proposed solutions to the adaptive image problem. Some very smart web developers came up with the idea of a <picture> element that works much like the current HTML <video> element. These developers thought they had the attention of the Web Hypertext Application Technology Working Group, better known as the WHATWG. Then, earlier this week, Edward O’Connor, Apple’s WHATWG representative, proposed another method of solving the problem, using a new srcset attribute on the <img> element. See our earlier coverage of the srcset attribute for a more detailed look at how it works and compares to the <picture> proposal.

What has web developers up in arms is that Ian Hickson, editor of the WHATWG spec (and better known as Hixie) has already added the srcset attribute to the WHATWG’s HTML draft spec, seemingly ignoring the months of effort that went into <picture>. Worse, members of the WHATWG apparently weren’t even aware that developers were putting forth the effort to come up with a solution via the Responsive Images community group. Nor were concerns about the srcset syntax given much consideration. Hickson does address some objections to srcset in his message to the WHATWG, but ends up dismissing most of them.

That doesn’t match up with how most people envision the web standards process. But as web developer and standards advocate Jeremy Keith writes, “this is exactly how the WHATWG is supposed to work. Use-cases are evaluated and whatever Hixie thinks is the best solution gets put in the spec, regardless of how popular or unpopular it is.”

In fact, think of the WHATWG as the source for initial, rapid development of new features. The group was started by browser makers because the W3C’s HTML Working Group (HTMLWG) moved too slowly. But if the WHATWG is the source of rapid development, the W3C is an effective check on that speed, ensuring that even those of us who don’t make web browsers still have a voice in the future of HTML. (see our earlier overview for more on the history and differences between the HTML WG and the WHATWG.)

While the HTML WG is also chaired by Hickson (a position he will soon step down from), it offers a much more democratic (and consequently slower) process and has overridden the WHATWG’s rash decisions in the past. For example the W3C added the time element back after Hickson removed it from the WHATWG spec.

Confused yet? It gets worse. The WHATWG is working on an ever-evolving standard, what it calls a “living standard,” which is different from — and may well diverge from — the snapshot-based standards issued by the W3C, like HTML5. In a comment on longtime web standards champion Jeffery Zeldman’s post on the matter, Jeremy Keith writes, “I don’t mind if the srcset attribute is in the WHATWG HTML spec but not in the W3C HTML5 spec. If it works, it’ll end up in a future W3C version number.”

Implicit in Keith’s statement is that if the srcset attribute doesn’t end up working out it won’t be in HTML5.x and would likely just fade away like the blink tag, the applet tag and other HTML ideas tried and later discarded.

Which is another way of saying developers need not panic. Perhaps web developers don’t have a voice in the WHATWG simply because we’ve been using the wrong channels (W3C community groups don’t seem to be an effective means of communicating with standards bodies, in fact they seem more like this.). If you’ve got ideas and would like a voice in the future of the web join the WHATWG mailing list and login to the IRC channel. Introduce yourself, learn the rules and contribute.