Responsive images – interim report
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 <picture> 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’s disliked by oiks who actually make web sites and fails to satisfy the art direction use case that 27% of those oiks currently polyfill to address.
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? Clever, but ultimately unsatisfying workarounds.
Firstly, have <img> 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 <video>s, and take advantage of media queries on the child <source> element to send differently sized images. Ian Devlin dreamed this up, and it’s evil genius – except that file sizes increase and <video> doesn’t have an alt attribute, so the “images” are therefore inaccessible.
A similarly inaccessible technique for webkit browsers is simply to use a <div> element instead of <img> and set an image-set background-image in CSS. Don’t do this; it’s inaccessible, and is single-engine.
The current best way is brilliant albeit somewhat hacky: Estelle Weyl‘s clown car technique. This uses a data-encoded SVG file, embedded using an <object> element. Unfortunately, there’s nowhere to hang alt text, and 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 which don’t address the important art-direction use-case.
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.
Buy "Calling For The Moon", my debut album of songs I wrote while living in Thailand, India, Turkey. (Only £2, on Bandcamp.)
20 Responses to “ Responsive images – interim report ”
I have made a javascript solution that also works without javascript (contradiction indeed). Its on GitHub including demo. The only drawback is that the source code gets noscript tags which is fugly. Estelles technique is pretty amazing!
Hi Bruce,
Images should be chosen depending on the width of their parent (not viewport size), is it possible with client hints header (??)
We need art direction…
Another technique is a “false” img with a transparent gif (or png) and showing the right image with css (img or an empty div)
For the clown car technique, the last version by Estelle Weyl is an <object> with the svg into the data attribute (url)encoded (needed for ie).
“you need to encode images” No I don’t think so. Only the right image is requested.
The image shown depends on the width of the parent.
Fallback ? <img> inside object (one more request… but I think we have solution to avoid it)
The clown car technique can be used **now** without extra javascript.
Is it a future proof solution ? Maybe not, but now we can use this technique and picturefill (jquery + picturefill)
For the css technique or clown car maybe we can add a link with title
<a
title="alt text"
href="img src"
>
<object>
<!-- fallback -->
</object>
</a>
(with a download attribute ?)
We have some solutions, with or without js, maybe we should try to make them better (to address accessiblity problems)… some reactions on Twitter were hostile while Estelle Weyl was experimenting (“bad: more requests” –for one step with external svg)…
Pascal
Worth noting that Microsoft does officially support the `picture` specification, though they’re very quiet on the subject.
Thanks for this summary, Bruce.
Firstly, have
<img>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.
Most of these methods (such as Riloadr) also add the mobile image in a <noscript>, so an image is still shown even with JavaScript disabled. It might not be the ideal image, and has “the elegance of a wading hippo” (Mairead Buchan rocks), but it’s not as bad as images requiring JavaScript as implied.
One minor disadvantage of this technique I’ve found is even if you add dimensions to an <img> lacking a valid src, browsers don’t reserve space in the layout for it. Apart from that it’s worked well for me.
Finally, hats off to Estelle for Clown Car. Impressive!
For the dummy source technique, a possible purely CSS solutions could be utilizing the box-sizing property as I wrote about here Replace the Image in an img with CSS on CSS Tricks blog. Ya think?
Its exciting to see some possible progression with this, but as you quite rightly said its not an ideal / un flawed solution and needs addressing correctly to create a robust solution instead of half solutions or dependant ones.
what about this one: http://adaptive-images.com/ ?
[…] The two solutions have been joined into what’s called “Florian’s Compromise.” However, the traction isn’t quite there […]
[…] joined іntο whаt’s called “Florian’s Compromise.” Bυt, thе traction isn’t quite thеrе […]
[…] The two solutions have been joined into what’s called “Florian’s Compromise.” However, the traction isn’t quite there […]
[…] The two solutions have been joined into what’s called “Florian’s Compromise.” However, the traction isn’t quite there […]
[…] The two solutions have been joined into what’s called “Florian’s Compromise.” However, the traction isn’t quite there […]
[…] The two solutions have been joined into what’s called “Florian’s Compromise.” However, the traction isn’t quite there […]
[…] Responsive images – interim report […]
[…] The two solutions have been joined into what’s called “Florian’s Compromise.” However, the traction isn’t quite there […]
[…] recent days, weeks and months a lot was written about responsive and therefore retina images. We as a developer community have a […]
[…] The two solutions have been joined into what’s called “Florian’s Compromise.” However, the traction isn’t quite there […]
[…] The two solutions have been joined into what’s called “Florian’s Compromise.” However, the traction isn’t quite there […]
What makes the picture element such a bad solution?
BTW Mat “Wilto” Marquis asked us to fill out this survey during his presentation on this subject at mobilism. It seems that quite a few people are interested in the picture element. Not so much in the srcset attribute.