On the publication of Editor’s draft of the <picture> element

On Tuesday, a w3C Editor’s Draft of a proposal for HTML Responsive Images Extension was published, edited by Matt Marquis and Microsoft’s Adrian Bateman:

This proposal adds new elements and attribute to [HTML5] to enable different sources of images based on browser and display characteristics. The proposal addresses multiple use cases such as images used in responsive web designs and different images needed for high density displays.

It’s a mash-up of the strawman <picture> element I proposed in December last year, and the Hixie-blessed srcset attribute on img proposed by Ted O’Connor of Apple. (See Responsive images: what’s the problem, and how do we fix it? for more background.)

Of course, the publication of an editor’s draft means nothing. There isn’t any indication that any browser manufacturer will implement it. Philip Jagenstadt of Opera (but speaking personally) has already commented

Personally, I don’t think it’s a good idea to reuse the syntax of <video> + <source>, since it invites people to think that they work the same when they in fact are very different. It could be made to work, but the algorithm needs a lot more detail. Disclaimer: This is neither a “yay” nor “nay” from Opera Software, just my POV from working on HTMLMediaElement.

Those eager to bash Hixie and the WHATWG are using the new spec as if it were a cudgel; “this is how you deal with Hixie and WHATWG” says Marc Drummond.

I don’t think that’s productive. What is productive is the debate that this publication will (hopefully) foster. Two different but connected issues need debating. Firstly, the technical debate needs to continue. There are problems with the <picture> element, such as Philip points out, and its verbosity and potential to be a maintainability nightmare, as pointed out by Matt Wilcox.

And we need to work out how all can play a role in specifying the Web. The W3C dropped the ball with XHTML 2 because it was a philosophically elegant, intellectually satisfying specification that bore absolutely no relevance to the real world.

WHATWG picked up that ball, and grew the Web, because they knew what developers wanted: Flash and Silverlight’s application capabilities. The browser manufacturers who made up the early WHATWG knew that if those capabilities weren’t added to browsers, they would die.

But the gatekeepers of WHATWG aren’t jobbing developers or designers. Nothing wrong in that: neither am I any more. But their inability or unwillingness to account for the art direction use case has caused them to drop the ball here.

We need to get everyone’s voices heard: — people like Philip with implementor’s experience, people like Hixie with his encyclopaedic understanding of how specs inter-relate, and also solicit and understand the needs of those who make websites but can’t express their requirements in the language of specs, algorithms and IDL.

I don’t know how we can do this. The CSS Working Group had designers attending as invited experts for a short while, but I’m told that wasn’t particularly useful for either group. A group of designers called the CSS Eleven hailed themselves as “an international group of visual web designers and developers who are committed to helping the W3C’s CSS Working Group to better deliver the tools that are needed to design tomorrow’s web” and then promptly disappeared.

So congratulations to Matt Marquis and the others in the Responsive Images Community Group who have had the staying power to produce a spec for discussion.

Hopefully, this strawman spec can be refined into something workable that gives developers a simple, declarative way to send different-sized, art directed images depending on bandwidth and device characteristics. This means organisations waste less bandwidth, and it’s a faster (and cheaper) Web for consumers — you know, the great unwashed that we make websites for.

Added 8 September: The road to responsive images – useful introduction to actually authoring it in your websites.

8 Responses to “ On the publication of Editor’s draft of the <picture> element ”

Comment by Charlie

Great post. I’m going to stick by my position that trying to solve this problem only with markup is fundamentally flawed. As you say, now there is a strawman for people to work with. As I think some of the premises are dubious I am not convinced that this approach can lead to a satisfactory conclusion but let’s see where it leads.

Comment by Justin Avery

@Charlie are you hinting that this needs to be done on the server side or we need to introduce a new image type into the mix?

This was touched on at the end of Christopher Schmitt’s presentation for the responsive design summit, a rpng image type that follows similar to the existing .ico implementation.

Comment by Charlie

@Justin
Yes, that is exactly the approach I would favour. I’ve not heard of that presentation and my favoured format would be webp because of it’s fantastic compression ratio and quality both for photos and images with lots of text. Those factors are, of course, less relevant than the .ico kind of packaging but switching to a better format would already alleviate some of the existing problems. Something like mod_pagespeed should make implementation fairly painless and locate the problem in the communication between UA and server, which is where I think it is, and also be a good separation of concerns. The markup suggestion bundles too many eggs in one basket.

Comment by bryan

This is a never ending debate. There is so much potential to the way these images get handled. Hopefully its worked out sooner than latter.