Responsive Images — Solutions To Our Problems

Posted: 23 Dec 2013 05:30 AM PST

When it comes to all the different responsive image solutions out there, I have to admit I find myself generally confused about what they are and which one I might use. It seems like every other day someone posts a new solution to cure our responsive image issues.

Last week I discussed those issues and grouped them into several categories, flexibility, performance, aspect ratio, and art direction. When you get down to it though, there’s really one major issue and that’s wanting the ability to serve the most appropriate image to a given device under a given set of conditions. The other issues are all relatively easy to solve by comparison.

Ideally we want the ability to serve the most appropriate image to any device under any given set of conditions

In fact whenever you see someone talking about a responsive image solution, it’s likely a way to deal with this single issue.

Instead of trying to walk you through the details of different solutions, I want to offer more of an overview and point you to resources that do provide the details.

My goal is to point you to some great resources you may or may not have encountered. I’ll start with solutions to the easier problems and work up toward the major issue.

Flexibility

Making images flexible is quite easy. Set max-width to 100% for all images and they’re flexible. If you’re using html5 video do the same for all videos and you’re set. Same for html5 audio. If only it were that easy.

In practice we still end up using Flash audio and video and we likely embed videos from YouTube, Vimeo, or some other source. The good news is solutions are out there and they aren’t difficult to implement.

You’ll notice FitVids.js features prominently in the links above. I think more people are switching to FluidVids.js, but from my understanding both work equally well.

The first 2 links above are html and css ways of dealing with videos and don’t require additional Javascript.

Aspect Ratios and Hierarchy

Dealing with aspect ratios and hierarchy is also relatively easy to solve. First add height: auto to the max-width above to ensure images maintain their aspect ratio when resizing. The hierarchy part of the equation requires a little more work, though nothing overly difficult.

In general the solution is to set overflow: hidden on the image container and then adjust the positioning of the image inside to effectively crop it. There’s also a hack involving padding, which is similar to that used for flexible videos.

Background Images

I mentioned last week that background images deal with the same responsive issues, but have different solutions. Here are a few responsive image solutions that involve background images.

Optimizing Images

Part of the performance issue is simply about optimization. I’m surprised to still find images online that haven’t at least been run through some kind of image optimizer. In addition to saving images for the web and compressing them in an image editor, I run all images through ImageOptim. Smush.it is another popular image compressor and you can find more if you choose.

Naturally switching from bitmapped images to vector images like SVG and icon fonts will reduce image weight in addition to make your images flexible. I think vector images deserve a post of their own though so I’ll hold off saying too much about them here.

An optimization technique introduced last year was compressive images. It suggests a way to use a single image for both retina and non-retina displays and avoid to some degree the need to serve different images to different devices.

The last link above is the results of a test I ran, which didn’t seem to indicate compressive images worked quite as suggested, but I admit it wasn’t the most scientific of tests and more likely than not it was my test that was flawed and not the method itself.

Serving Appropriate Images: Waiting on Standards

The gist of this issue is wanting to serve different images to different devices and different conditions. There are 2 issues within this issue.

We’re currently limited in the conditions we can sense.
Images will generally download before any code we might use to determine which is the most appropriate.

The first issue is something we’ll likely need to wait on. The second is what most responsive image solutions attempt to fix.

Ideally we won’t have to do the sensing and the browser will do it for us. That’s ultimately what should happen once everyone settles on a standard. You and I will write code that will work similar to a media query that says use this image under these conditions and use that image under those conditions.

Unfortunately that standard isn’t settled. The two main approaches that have been considered are the picture element and the srcset attribute. Designers and developers prefer the former, while browser makers prefer the later. It seems the browser makers are winning and the picture element is now off the table. However, browser makers have added a wrinkle by proposing src-n, which is similar to srcset. It potentially offers us more, but isn’t quite as ready as srcset.

My head is starting to hurt thinking about it so let me point you to others who can explain what’s going on better than I can and who can also provide more details about how this will all work.

Here are a couple of links specifically about the picture element, though again, it sounds like we won’t ever see it.

And here are a few on the srcset attribute, which we likely will see (It’s in Webkit, though not Safari yet), unless src-n wins out.

There’s also the image-set() notation, which is like srcset for background images, though it’s currently part of an Editor’s Draft.

Update: More changes and more head spinning. Seems like src-n and srcset may now be out and the picture element back on the table. Mat Marquis has a year end roundup to explain.

Serving Appropriate Images: While We Wait

Since the standards aren’t ready yet, people have been working on solutions that for the most part do what the standards will eventually let us do. I’m not even going to pretend this is a comprehensive list of methods or that I really understand how each of these works. The links below will lead you to people who do and who can fill you in on the pros and cons of these and other methods.

Jason Grigsby has written several articles on responsive images that offer quite a few different solutions as well as their various pros and cons. Sherri Alexander offered thoughts on how to choose a responsive image solution and Chris Coyier did the same as well.

The sources above might be all you need, but I’ll point you to a few more below. Scott Jehl created picturefill.js, to mimic what the picture element was going to offer. Interchange comes from Zurb as part of their Foundation framework. Both progressively load images. You choose an image to load by default and then the scripts load additional images only as needed based on media queries.

Lazy loading is a technique to hold off loading images until they’re needed. Imager.js is a not quite ready for production script based on the BBC News technique for loading images. The case study below combines parts of several methods to arrive at a solution.

Sever side solutions also exist. The idea being that you send information about the screen to the server and the server then creates or serves the appropriate image

In time we’ll likely be using whatever standard evolves and only those sites with very specific requirements will need to look further. The standards aren’t here though, so for now it’s either one of these solutions or delivering a single image to all devices and conditions.

Summary

Is your head spinning? Mine is. Making images and media flexible is relatively easy, as is dealing with the aspect ratio problems that crop up. Being able to serve different images to different devices under different conditions? Not so much.

In time standards will be in place that will help. The picture element looked like a nice way to serve different images, but it doesn’t look like we’ll get it. The scrset attribute and perhaps the src-n attribute don’t look quite as easy to use, but neither is hard to use and if they solve the problem we’ll learn.

Until the time when a standard evolves and we can safely use it in production, we can choose among the variety of solutions that try to mimic the functionality that standards will eventually bring. None are perfect though, and you may decide none are worth implementing, choosing instead to balance the simplicity of serving a single image with the potential decrease in performance.

There’s more to cover where responsive images are concerned. After the holidays I’ll pick up the discussion again with some thoughts for how we should be thinking about images long term.

If you liked this post, consider buying my book Design Fundamentals

The post Responsive Images — Solutions To Our Problems appeared first on Vanseo Design.