Stretchy Pictures

Saturday 2nd Jun 2012

There’s a thing going on about responsive images on websites: making sure the person looking at the page is delivered the right pixel and file size of image for their device and conditions. I’ve read around the subject and done some experiments, and to my mind we can’t fix it properly for a couple of reasons, but there are some interesting other things we can do instead. So, first off, the couple of reasons:

The first is that we can assume some things, but not all things. A small screen doesn’t necessarily mean low bandwidth, in the same way that using an iOS or Android device doesn’t actually mean you’re mobile (I use my iPad on the sofa, a mere 2 metres from the wifi hub). We can do clever things with guesswork, but there are few things more frustrating online than visiting a website and being given a degraded experience because of incorrect assumptions. I rage about such things. So to sum that all up, we need the browser, the OS and the network to cooperate and tell the page (either at the client or server end) what the situation is, i.e. is it a good network connection, is there much processing or memory capacity on the device, and what can the browser understand. Can the thing be downloaded (at all? quickly?), can it be loaded and can it be interpreted properly? We needed this years ago. Really.

The other reason is an extension of the first. Does it matter at the moment? This article puts it rather well. We can’t make it perfect, but giving the user something is better than nothing. We can to an extent trust that OSs and browsers can handle chunky and demanding pages, even if they don’t do it well. Of course we know the page shouldn’t be chunky or demanding unless you’ve got a damn good reason for it, but assuming you have that reason, best to deliver it and hope for the best rather than ACCESS DENIED (download our app!). Which isn’t friendly.

Anyway, I was thinking of all of this as I was updating my awesome new portfolio which is awesome (hire me) I think you’ll agree. (Sorry). I wanted to include pictures of my projects that worked on large and small screens, but didn’t want to lose the vertical rhythm of the page (such as it is) or by having poky hard-to-make-out images at one scale and dirty great pixels at the other. I also needed something that would work with the diversity of projects I’ve worked on; illustration, IA, UI design, branding, HTML & CSS and so on. A simple screenshot wouldn’t work here.

I had of course read the hoo-hah about the picture tag vs. srcset (written up nicely by Jeremy Keith here), and it gave me some ideas. I know the picture element isn’t meant to be a container tag for lots of pictures you’d show all at once, but what if it was? The orthodox way of it is that there’s one image you show (say) when space is limited, another when there’s more space, yet another when it’s a high-res display, and so on, with only one of the set being shown at any one time. What if you could show all of them at once, in some form?

So that’s what I did. There’s an image tag which always displays, and I’ve made that image the one that fits on pretty much all screens. There’s a background image too, because there are a couple of container elements around the image - a div and a p. So I put a background on the div. Then, as the display gets larger, I add an image using :after to the p, inside a media query. Then, as the space increases, I put a background on the p. I could use :before as well for another image, and attach some to the container div in the same way, if I wanted.

So it’s a bit of a faff to arrange, but the results are exactly what I was after: a collage of images to give an overview of the project, that responds to the viewport and doesn’t download images it isn’t going to show. In other words, a responsive picture. Ithangyou.