A Consensus to the Responsive Image Problem?

Tweet

Responsive Web Design is a simple technique until you consider images. There are a number of issues:

  1. Bandwidth can be saved if smaller images are sent to smaller-screen devices.
  2. On lower resolutions, it may be preferable to show a cropped image with the main detail rather than a resized view of the whole image.
  3. Devices with higher-density displays (Retina) could be sent higher resolution images.

I have a suspicion the problem has been overstated. Few of us will ever bother to create numerous device-targeted images; there are too many options and life is too short. That said…

Are Displays So Different?

If we look at the lower end of the display spectrum, we find mobile phones. Even the cheapest smartphone has a 800×480 display. That’s approximately half the dimensions (quarter the area) of a mid-range laptop but it’s still a reasonable resolution. And remember the browser runs full-screen which few people would do on a PC.

To the other extreme we have double-density displays, commonly known by Apple’s trademarked term — Retina. Recent iPads have a native resolution of 2,048×1,536 or 264 pixels per inch where individual pixels can be too small for the naked eye. To ensure websites and apps remain usable, the device reverts to a standard 1,024×768 resolution but uses the extra pixels for smoother fonts and icons.

My point is: display specifications are converging. High-end mobile resolutions already match or exceed typical PC screens and display densities can only go so far; why create triple-density displays when double-density pixels are already invisible? The need for responsive images will reduce as hardware improves.

My Images are Blocky!

I’m yet to be convinced Retina image quality is a major problem…

  • Images are usable.
  • Relatively few people (currently) own double-density devices.
  • The majority of Retina devices are smartphones and tablets. Should we be sending higher-resolution images to gadgets with more limited processing power and network availability?
  • Finally, why are we adding high-resolution photographs to our websites when bandwidth and responsiveness remain so important?

Of course, none of this matters when your boss demands “less-blocky” images on his iPad. However, I would recommend a more pragmatic cross-browser approach in preference to larger images, i.e. replace bitmaps with SVG images, CSS3 effects or webfont icons when possible (refer to 5 Ways to Support High-Density Retina Displays).

The Industry Decides

I may be slightly dismissive, but many people care about the responsive image problem. A recent meeting of W3C members finally reached a consensus and vendors are likely to support the image srcset attribute proposal. When implemented, you will be able to use code such as:

<img src="normal.jpg" srcset="midres.jpg 1.5x, highres.jpg 2x" />

Devices with standard resolutions or browsers which don’t support srcset will load normal.jpg. Devices with 1.5x density screens will show midres.jpg and 2x density screens will show highres.jpg.

Unfortunately, pixel density is not the only factor and the viewport width (and possibly height) should also be considered. Therefore, srcset could eventually support the following cryptic syntax:

<img src="x.jpg" srcset="y.jpg 800w 1x, y.jpg 400w 2x, z.jpg 1200w 1x, z.jpg 600w 2x" />

In this example, y.jpg is loaded on standard-resolution devices with a maximum 800 pixel width and double-density devices with a maximum 400 pixel width.

srcset is hard to read, prone to errors and I suspect it will be too easy to incorrectly target or miss a range of devices. However, it was considered more backward-compatible and easier to implement than other proposals.

Of course, the proposition could still change. I have a horrible feeling we’ll all be using double-density displays and extra-large images before this becomes a usable standard!

Do you like the srcset proposal? Would you use it?

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Alexander DiMauro

    In the second paragraph of the ‘Are Displays So Different?’ section, you wrote: ‘To ensure websites and apps remain unusable,’…UNusable? Is that a freudian slip? :)

    Anyway, it seems a bit tedious to include all of that text in an img tag. Since responsive design is based on CSS media queries, wouldn’t it make more sense to have the srcset in CSS rather than in the tag?

    • Anonymous

      unusable, usable … spot the difference! Oh. OK, fixed. Thank you!

  • Anonymous

    I worked on responsive websites for 2+ years and the Responsive Image Problem is the of the few ones that I never get satisfied by the solutions I found (by myself or not).

    The srcset is a good idea IMO. Picturefill is alike this solution, but integrating it in the HTML will make it more compatible and less likely to bug.

    That said, let’s hope that the W3C will validate this proposal sooner than later. And that the browser will integrate it quickly, especially the slowest ones (I’m looking at you, IE).

  • Anonymous

    There is another solution on the table, as well, that covers more scenarios. It remains to be seen what finally wins the day.

    • Anonymous

      Do you mean the proposed “picture” element? If so, that’s been dropped.

  • Rodney

    “Few of us will ever bother to create numerous device-targeted images; there are too many options and life is too short.”

    To the contrary, that is EXACTLY what we are doing! We, who create beautiful, snappy shopping experiences that best fit whatever device a site visitor is using. We, who serve our clients’ media to 1,000+ outlets with varying requirements, all properly cropped and optimized.

    While I agree that “there are too many options and life is too short,” I think you’ll find that very few of those options give enough control over a batch of resized images or save much time at all. We need something super fast and easy.

    For on-demand delivery of resized and adjusted images, try installing ImageResizer on your web server.

    For cloud-based batch image resizing, cropping, renaming and more that works seamlessly with Dropbox, Google Drive, or Box, use sizzlepig. Cuts our resizing and cropping time AT LEAST 80%.

    • Anonymous

      Ahh, but you’re automating it!

      The answer is: it depends. You’re running a shop, so quality images at different resolutions is more important than someone running, say, a news website.

      • Rodney

        Of course I’m automating it! I’m a “lazy” developer. Even so, I care about the quality of the final output (as do my clients), so pure batch scripting doesn’t cut it. I think sizzlepig is as close as it gets right now.

        Funny you should use the example of a news website! I met a developer from The Detroit News. They definitely care about quality images at different resolutions: multiple sized thumbnails of lead images for articles, photo gallery thumbs and enlargements, photos served in RSS feeds, hi-res/2x images, etc. They can’t be alone in the news world. (Look at CNN.com’s teaser tiles and how the photos are cropped perfectly even at an odd aspect ratio. Someone is likely doing all those by hand! Same goes for a number of e-commerce sites I’ve worked on.)

        Anyway, clients and site visitors care about the presentation layer… A LOT. I don’t think the need for responsive/adaptive images goes away with converging display specs since there are other criteria that affect which image is best to display in a given format.

        • Anonymous

          Don’t get me wrong – I’m not saying alternative images shouldn’t be created. However, I do think it’s (currently) a lot of effort for fairly little benefit. You need to create many different sizes to cover the majority of devices and I’m not convinced many site visitors would notice or care given the average time spent viewing a web page. A large shop (or news agency) may have the budget and resources to cover it; smaller companies wouldn’t.

          Put it this way, I’d rather receive an image which wasn’t optimized for my display than view another annoying “download our app” splash screen!

  • Grover

    “Relatively few people (currently) own double-density devices.”

    Is that really true? Like one in every 10 computing devices sold is a retina screened iPhone, and that’s before we even get to Apple or any other vendor’s other devices. Heck, they sold almost 10 million retina iPhones over a recent weekend.

    Not only that, much like the transition to HD video, once you own a high-resolution device, your tolerance for low-resoluion images is dramatically reduced. You notice it immediately, and immediately have a poorer impression of the website.

    I’m usually on your side when adapting most new technologies, and I can see an argument for not bothering with content photographs, but logos and UI resources absolutely should have 2x versions if at all possible.

  • Dotty

    Things I have not yet thought or cared about…was just wondering today if I really needed to create the 2X images for Retina that my WP theme offers.

  • james

    interesting but not quite the info laden solution full article I was hoping for…

    • james

      and yes, I suppose I would use it, but I’m not happy about it

  • Anonymous

    I can’t help it, but for me this whole idea of source-set attributes in HTML seems flawed.
    It would be much more convenient if browsers would send the essential viewport and resolution data within the request header to the server and there one could handle the delivery accordingly either programmatically/dynamically or by configuration.
    What do you think?

  • Ian

    Currently i’m using smaller images in content, like around 200-300 pixel widths that re-size on smaller screens and float none/center.

    This covers most layouts with up to a few images per page so bandwidth not major and images are optimized.

    If needing a full width banner/header image, then would have desktop/bigger screens use one background image and on smaller screens, replace with a better suited background image. That way only one background image loads based on screen size.

    Until a better solution comes along, then will stick with that.

  • Anonymous

    None of the above!

    This is a display issue, right? So it should be handled by CSS. Add an HTML tag that represents scalable images, and then call it in CSS.

    Done. No?

  • Anonymous

    No, Jeannie, because inline images are *content*, not simply presentation. Pushing everything back to CSS violates semantics.

    Now, of course, where the image is merely decorative or presentational, absolutely: a CSS solution is in order, which is certainly doable for imagery that repeats across a site.

    Even apart from the semantic issue, on a practical level, making all images CSS-based is simply not viable. Imagine a blog that uses an image corresponding to every post, or even more crucially, an ecommerce site that display product images. It would be an absolute nightmare to maintain that via CSS as soon as you got beyond a very small handful of products.

  • ralph.m

    @Ian3 “That way only one background image loads based on screen size.” Unfortunately, some browsers download all background images, whether targeted at them or not.

    My preferred strategy for this is the one suggested here: http://blog.netvlies.nl/design-interactie/retina-revolution/

    You set the dimensions of the image quite large, then reduce the image quality and set the width/height via CSS. You get a small file download AND a nice, crisp retina display. I guess the only downside is that not everyone has access to a tool that can resize the image and change the quality.

  • Joan

    As I remember, Smashing Magazine posted an article recently about implementing responsive images using noscript tags, then enhancing it with JavaScript.

  • Anonymous

    So, the W3C has the following guidance:
    “In case of conflict, consider users over authors over implementers over specifiers over theoretical purity.”
    http://www.w3.org/blog/2013/10/on-encrypted-video-and-the-open-web/

    I feel that srcset is a failure as a W3C standard in this light. This is clearly a case of favouring the browser vendors over site authors (e.g. web developers). The picture element proposal was far friendlier to web developers, but the browser vendors complained that it would be difficult to optimise.

  • Anonymous

    I think there should be CSS solution to this. If CSS detect that it is double density and alternate image location is provided then browser will trigger alternate download and leave the normal image download.

  • Jame5darlington

    Its a tough one, what happens if you have a, for example, a phablet double density display but a cap on download, or worse still poor reception thus a slow connection, fancy sites could lose customers from speed issues?

  • Anonymous

    Screw this, all the way. srcset is pretty much unreadable and it will be yet another thing where all browsers implement different subsets of the functionality. Thanks, but no thanks.

    • Anonymous

      I preferred that option, but it’s not very backward compatible. It’s been rejected.

  • Kian Ann

    Over the last couple of years, content publishing has been easing well towards the non-tech people – someone with a very basic understanding of HTML can log in to a WordPress blog, craft a new post, add in the text, upload, crop and align the images and hit publish. (even without a visual editor).

    Until the image uploading plugins / editors catch up, having more attributes like srcset is really gonna mess up things again, which is both a headache and opportunity for developers and designers, I guess!

  • Anonymous

    Right concern.