At Google I/O last week, I was hoping to hear Google’s thoughts on responsive images. Every developer I speak to wonders how to send the right image size to browsers, Google is obsessed with performance, Peter Beverloo and Paul Kin...
At Google I/O last week, I was hoping to hear Google’s thoughts on responsive images. Every developer I speak to wonders how to send the right image size to browsers, Google is obsessed with performance, Peter Beverloo and Paul Kinlan were explicit in their talk Mobile HTML: The Future of Your Sites that web sites should request the correctly-sized images. But how?
The element seems to be at an impasse; no-one from Google showed any enthusiasm (nor does any other browser vendor, seemingly). That’s OK; when I dreamed it up 18 months ago it was a strawman to get the conversation going in standards groups (I’d previously been told that there was no need for any standard, as everyone would have huge devices on reliable, fast wifi in the future).
We have the srcset attribute, with its wildly unintutive syntax, “ready for first implementation”, so supported nowhere yet. It also doesn’t satisfy the art direction use case.
Google has proposed a Client Hints header with device resolution, viewport size, touch-enabled flag etc. The idea is that the server generates lots of different sizes of foo.png, and when a request comes for foo.png, the server looks at the Client Hints and sends the most appropriate size. Opera (and soon, Chrome) announces that it accepts webP images, so the server could intercept requests for foo.png and send foo.webp in its place for conforming browsers, thereby reducing bandwidth.
This server-side negotiation will be great for legacy pages as it means source code doesn’t need to be touched. I’ve heard it also touted as being much simpler to author, but I wonder about that; HTML isn’t hard to write, while implementing server-side image resizing and transcoding, intercepting headers, doing the negotiation and setting cache control is much harder for an HTML wrangler than writing HTML is. It also assumes everyone has full access to the server. Don’t forget that some uses of HTML (for example, ebooks) have no server.
But those are all for the future. What can you do now?
There are a couple of nasty hacks. Firstly, have with a dummy source, then replace the src with JavaScript once you know the dimensions and resolution of your device. This makes images dependent on JavaScript.
Alternatively, make your images into single-frame s, and take advantage of media queries on the child element to send differently sized images. Ian Devlin dreamed this up, and it’s evil genius – except that file sizes increase and doesn’t have an alt attribute, so the “images” are therefore inaccessible.
A similarly inaccessible technique for webkit browsers is simply to use a element instead of and set an image-set background-image in CSS. Don’t do this; it’s inaccessible, and is single-engine.
A brilliant albeit somewhat hacky idea is Estelle Weyl‘s clown car technique. This pulls in a SVG image that embeds images encoded as data URLs, each surrounded by media queries. This has the advantage of removing presentational breakpoint information out of the HTML. The downside to this is that you need to encode images (to reduce http requests), so changing an image isn’t as simple as replacing it on the server, and there isn’t anywhere to hang alternate text. Right-clicking to “save as” doesn’t behave as expected.
So that’s the interim report. Inaccessible and/ or single-engine, or JavaScript-dependant, or relying on server-side shenanigans. Images are central to the web; we need a declarative HTML method to achieve them in our multi-device world.
I’ve done my part in suggesting a strawman, and although cleverer minds than mine tell me it’s a bad solution, in a year and a half no-one has told me what a good one looks like.
Fingers crossed.
