Skip to main content

A framework for discussing responsive images solutions

By Jason Grigsby

Published on May 3rd, 2012

Topics

Over the last few weeks many more web developers and designers have become engaged in the conversation surrounding responsive images. On the whole, this is great news because the more people we have telling browser makers that this is a legitimate issue, the more likely it is to get addressed quickly.

However, some of the conversations about responsive images end up going in circles because people are talking past each other. I believe this is happening because we don’t have a common framework to look at the problem.

I believe there are two separate, but related issues that need to be solved regarding the use of the img element in responsive designs. They are:

Permalink to 1. How do we enable authors so that they can display different images under different conditions based on art direction?

1. How do we enable authors so that they can display different images under different conditions based on art direction?

To understand this issue, it helps to look at a specific use case. Take for example the following photo of President Obama speaking at a Chrysler plant.1

Obama speaking at Chrysler plant

When the image is displayed at larger sizes, it makes sense for the image to show the automobile factory in the background. The background helps explain where the event took place and adds to the image. But look what happens when we scale the image down to fit a smaller screen.

Obama speaking at Chrysler plant shrunk to 100 pixels wide. Obama himself is tiny in the picture at this size.

At that size, you can barely recognize Obama. You can’t make out his face. Instead of simply resizing the image, it may make sense to crop the image to get rid of some of the background and focus in on him. The end result is an image that works better at the smaller size:

Obama speaking at Chrysler plant shrunk to 100 pixels wide and cropped so Obama can be seen better.

This is what I refer to as enabling art direction. Authors need to be able to provide different sources for images at different sizes not based on resolution or based on network speed, but based on the judgment of the designer for what is the best image at a particular breakpoint.

As an aside, showing photographs at different sizes to illustrate a point is more difficult when you’re dealing with flexible images in a responsive design. If those examples don’t make sense on your phone, I’m afraid you may have to look at it on a wider screen to see what I’m talking about! 🙂

Permalink to 2. Enabling authors to provide different resolutions of images based on a variety of conditions.

2. Enabling authors to provide different resolutions of images based on a variety of conditions.

When people talk about how to handle images for retina displays, they are talking about this second issue. The same is true of making decisions about the size of images based on bandwidth. All are dealing with how to deliver different resolutions based on conditions (pixel density, network speed, etc.).

Apple’s proposed addition to CSS4, image-set, is designed to solve this issue in CSS. Authors define images at different densities and the browser picks the best one based on some criteria that could be as simple as pixel density or as complex as a combination of observed network speed, pixel density, and user preference. What the criteria is remains to be defined.

Permalink to Where the <picture> element fits

Where the <picture> element fits

The proposed <picture> element attempts to solve issue #1. It focuses on how to give authors the ability to specify different images, but doesn’t do anything about pixel density or bandwidth.

I’ve seen a lot of feedback on the <picture> element that says we should have a new type of image format to replace JPEG, PNG and GIF that would be resolution independent. That would be awesome. And it would solve issue #2, but it wouldn’t help with the art direction outlined in issue #1.

When we discuss various solutions, it behooves us to figure out which issue we’re trying to solve. We can also debate whether or not the two issues I outlined are legitimate or if there are other issues that aren’t addressed by them.

But in order to have a fruitful discussion about how to solve these issues, we need to be clear about which issues we’re talking about or we’ll end up wasting more time. What I often see in comment threads and on Twitter is two people debating different solutions for responsive images, both looking at different issues, and neither realizing that the other isn’t looking at the same problem.

My hope is that by defining these issues, we can stop spinning our wheels and have more successful discussions.

  1. Photo of Obama licensed under Creative Commons. CC BY-NC-SA 2.0 by BarackObamaDotCom

Jason Grigsby is one of the co-founders of Cloud Four, Mobile Portland and Responsive Field Day. He is the author of Progressive Web Apps from A Book Apart. Follow him at @grigs.

Comments

Miguel said:

Certainly, Responsive Images ain’t a easy thing to come up with and these two issues that you mention here are the reason that I haven’t decided to implement the Responsive Web Design on a larger site, an e-commerce website to be more precise. But eventually I know we will solve this.

gray ghost visuals said:

The picture element is a great start and beginning to solving this issue but as you said we are indeed talking past one another.

Obviously the idea of responsive images is still a large issue to solve, but what I can say at the moment is what I do like and what I do like is where we are going with base64 encoding and SVG as either a .svg file or embedded within the markup. The usage of these two methods would obviously be terribly hard to maintain for sites like Flickr but they do hold their place in the mix of the discussion.

The image above of our friend Obama Mama is a great example of why we cannot just squish an image down just to say we made it “responsive.” However it does make the day shorter and the time to get home for dinner much closer.

Brett Jankord said:

I’m a fan of the current proposed picture element, I believe it does a great job of solving most of the issue you’ve brought up here.

In regards to your issue of enabling authors to provide different resolutions of images based on a variety of conditions, here is an example of how the picture element could be used to handle displaying images on high resolution devices.

The issue I see arise with the picture element markup is that it becomes very verbose, and in my opinion, not ideal from maintenance standpoint. We would be repeating our CSS media queries on each of our picture elements on each page of our site. And when you decide to redesign, you’d have to go through all of your picture elements and update the media queries if you changed your breakpoints. This is the one issue I have with the current picture element. Otherwise, I think it solves most all of the issues with displaying images on devices with multiple screen sizes and resolutions.

I’ve put together some markup as a concept of an optional alternative method for writing the logic for responsive images based on the current picture element, image-set CSS, and URI templates that would alleviate the maintenance issue and keep picture elements DRY.

In regards to displaying high resolution images based on connection speed, this is somewhat of a can of worms to me. It would require a lot of processing that might be better left to the user to decide on their own. Rather then checking the users connection speed, which may change as the user is on your site, let them specify if they want standard definition images or high definition images on the browser level just like the user can choose their own default font size.

By letting the user have a choice, you can provide high resolution images to users on a slow connection who don’t mind the wait or provide standard definition images to those on a fast connection but don’t necessarily need retina images eating up their monthly data.

Another thing to consider when thinking about displaying images based on connection speed is that what is fast for user A may be slow for user B. Chris Coyier recently took a poll of his users connection speed. The results were pretty interesting.

Ben Callahan said:

Thanks for clearly stating the distinction. In my mind, the “art direction” concern (despite the name you’re using for it) is a content problem as opposed to only adjusting the scale of the image, which feels more like a presentation problem. Do you agree with this distinction and do you think it implies an HTML (for content issues) vs CSS (for presentation) solution? Or, perhaps this is oversimplifying the issue…

Looking forward to seeing some viable short-term solutions to these issues emerge while we work to get more appropriate long-term answers in place.

Adam Bradley said:

I think you’re dead on with what the two distinctions are. Really, a solution for responsive images and hi-res images both hit us at about the same time, and they both require variants of the same image to display according specific scenarios. I feel many of writers of the blogs, comments and tweets, had either responsive or hi-res images in mind, and each of the readers of those blogs had one of the two in mind, causing even more confusion and spinning off discussions when they weren’t on the same page. So you’re absolutely correct that this needs to be defined. But whatever solution ends up being, it should answer both issues.