Responsive images – end of year report

Celý článek

It’s nearly two years since I suggested a <picture> element as a strawman proposal as a way to solve the problem of responsive images, so let’s have a look at how we’re doing.

In September there was a big meetup at Mozilla’s Paris office organised by Mozilla’s Marvellous Mr Marcos who’s been very active in the Responsive Images Community Group and did the hard work of actually turning the <picture> strawman into a spec. Such is the combined allure of Marcos and Paris that a rep from Apple showed up – kudos to Edward O’Connor.

The outcome of the meeting was that <picture> isn’t a viable option. Browser makers don’t like the fact that it’s a new element that does the same as <img> (or what <img> should do if we were speccing it today), and that it depends on multiple nested children. I’d based this on the HTML5 <video> and <source> pattern, but Ian Hickson already said “we learnt with <video> and <source> that having multiple elements for selecting a resource is a huge design pitfall”.

The Paris meetup’s most immediate outcome was agreement that srcset + DPR-switching is the right initial step forward (i.e., the 2x, 3x, etc. syntax). (See Marcos’ full write-up for more fun.)

srcset was specified as part of the WHATWG specification and a draft extension to HTML5, based on Edward O’Connor’s imgset in CSS that’s already implemented in WebKit. It’s fair to say that the syntax hasn’t been received with enthusiasm by developers, as it is ugly and unintuitive. But for the simple case of sending a large image to high-dpi displays and not to 1x dpi displays, it’s simple:

<img src="normal.png" srcset="retina.png 2x" alt="otter vomiting">

Browsers with two or more device pixels per CSS pixels (“retina”) get the 2x image; other browsers, including those that don’t understand srcset get normal.png as specified in the traditional src attribute. Hurrah!

This limited version of srcset is already implemented in WebKit nightly, but not shipping, and was about to be implemented in Gecko and Blink when a proposal from Tab Atkins and John Mellor of Google called src-N made a fashionably late entrance.

It’s not the easiest syntax in the world, either, but src-N does address the three main usecases:

• devicePixelRatio based resolution switching
• viewport-size based resolution switching
• art direction

The simplest incarnation – serving high-dpi images only to browsers that can deal with them is

<img src="normal.png" src-1="normal.png 1x picHigh.png 2x" alt="narwhal regurgitating">

An explainer email shows how verbose <picture> can be for a real sites, while a blog post from Tab Explaining The Last Clause of the src-n Grammar shows a more verbose example of src-N while comparing it with its srcset analogue which is, Tab says, “fucking terrible” – much longer and harder to maintain, requiring non-trivial maths.

All the proposals are verbose and tricky. I suspect that this is simply because it’s a really hard problem, but it is one that needs solving. Tim Kadlec’s posts on Why We Need Responsive Images quantify the bandwidth that we currently waste, and wasted bandwidth costs money and slows down the site for users which has a measurable and significant impact on your sales.

Since src-N has been proposed, both Blink and Gecko have decided not to implement srcset which is currently not yet shipping in WebKit. A representative of Apple called src-N‘s use of multiple attribute “a grotesque perversion of the HTML language“, which implies they’re not eager to implement it. (We’ll ignore the irony that the company which gave us a meta tag in HTML to control presentation is accusing others of perverting HTML).

Meanwhile, the src-N explainer says “Ideally, browsers that have already implemented the basic srcset syntax would remove that as soon as possible before sites start to depend on it”, but goes on to note “it would be possible for such browsers to integrate srcset, just like src acts as a fallback”.

Adam Barth, a Blink rep, writes “I’d rather ship something that’s useful today and iterate to improve it in the future than not ship anything for a long time”, which is fair enough – but Henri Sivonen of Mozilla counters “I think srcset should be taken out of the spec ASAP before WebKit ships it and we get stuck with something that doesn’t allow iteration”. The bone of contention – is srcset subsequently extensible?

Given that src-N addresses more usecases than WebKit’s proposed dpi-switching srcset and the similarity of syntax, I wish WebKit would simply alias their nightly code and ship the minimal dpi-switching src-N given above (so src-1 instead of srcset) and argue about discuss extending it later.

But no. So, once again, impasse. Our doctors’ report: must try harder.

Added 13 November 2013: It’s been pointed out to me that srcset is also implemented in Blink, behind the “experimental features” flag. Demo. The point, however, is that it’s not shipping anywhere so no websites rely in it, and it’s not in Firefox or IE.

Added 2 January 2014: Given the impasse described above, the proposed <picture> element has been revived again and new <picture> specification is under development that combines the best features of all proposals. The most important difference from “old” <picture> is that the <source> elements control the src of the <img> element; thus, <img> is an integral part of the construct rather than simply fallback (and thus is unlikely to be omitted by authors, so “old” browsers won’t be left out.)

Responsive images – end of year report originally appeared on HTML5 Doctor on November 12, 2013.