Responsive Images: Experimenting with Context-Aware Image Sizing

This is great.

For further reading, see tinysrc.net - I’m trying to see how I can work your ideas into the way it works. More thoughts welcome!

(tinySrc uses either explicit screen-size declaration or device-specific sizing - so might be useful for those instances when you don’t have control over the images being pulled into your app or you’re also dealing with non-JS-friendly clients)

Looks great on my Droid and imac

This would be the perfect place for content negotiation. Anyone else think a “Vary: Resolution” header is in order?

It would be better to have ‘progressive’ images and the browser aborts the download when it has good enough resolution of the image.

“To use, just drop the .htaccess file into your root web directory (this requires an Apache web server”

- Does this mean it is not possible with IIS?

Lorro, should be possible in IIS.  All the .htaccess file does it some URL rewriting.  You would just need to translate those rules to routes or some regex based rewrite rules.

Awesome Scott—I will be working this into my projects which use Responsive Design. #IOU-Beer

Tested the demo on firefox 4 “minefield” with last build.
No “double” image download.
It seems to be working fine.

This is fantastic. Absolutely amazing work. I love responsive designs. It just makes good sense.

I’ve been wrestling with this problem myself for the past few weeks, which is how I came across your article. I’ve written up my attempt, would be interested to see what you think.
www.craig-russell.co.uk/responsive-images-and-context-aware-image-sizing/

I’ve just found you cited on Smashing Magazine’s article about responsive web design.
Just a question: I know that I can use custom data attributes with HTML5, but could it be feasible/easier (and useful for use with non HTML5 websites) to use your solution without “data-fullscr”?

You already rely on a rule - the “.r” prefix - for mobile-friendly images, I think you could add a second rule, adding by default another prefix when using of fullsize images is needed: “fullsize_” (or whatever else).

So in case of responsive images, you would have this code <img scr="test_image.r.jpg" > converted by your Javascript file in <img scr="test_image.jpg" > for small display and <img scr="fullsize_test_image.jpg" > for bigegr display.

Useful, I think, for using with no HTML5 - but responsive and standard compliant - webpages.

Thanks everyone.

@Lorro: You may be able to get it to work on IIS or other server setups, but the URL rewrites will need to be adapted to work in different environments. Here’s an article about converting htaccess directives to IIS: learn.iis.net/page.aspx/557/translate-htaccess-content-to-iis-webconfig/

@Guillaume: thanks for the heads up! Indeed, this does now work (1 request per image) in Firefox 4 :)

@Craig: we commented on your article, but in general, PHP-generated image sizes could be a fine solution. However, we do think it’s important to serve a functional image in the base markup rather than a 0px gif (so that older devices including those with JavaScript unavailable receive the content too), so we wouldn’t recommend removing the scripts and rewrites we’ve produced to facilitate that.

@ilpiac: That’s a good point. If your server is configured in a reliable way, you could do without the data-fullsrc attributes and simply redirect any images with the “r.” extension prefix to their full size image file immediately. Doing so would likely require a fixed pattern for your file naming conventions, where you can trust that an image’s full-size equivalent can be found through a consistent change in the filename (for example, police.jpg becomes police.full.jpg or even police.jpg?full). We didn’t want to impose any filename pattern constraints on users of this script, which is why we went with the data-fullsrc approach, but if you can set things up to work like that, it sounds great!

Hi everyone,
I just pushed a new version of this technique that is significantly streamlined, and much improved. The new approach sets a cookie to store screen resolution, and the server immediately redirects to the appropriate image size. Also, the data-attr driven approach outlined above still works too, if you need the flexibility of data attributes (if your filenames are not consistent, predictable). Otherwise, the new script assumes a filename convention of (image.jpg vs. image.large.jpg) by default.

Also, this approach will work on any browser that has cookies and javascript available, which is likely a much broader range than the initial script. Of course, browsers without cookies or JS will just get the mobile image size, so whether it “works” is a matter of experience level rather than a general accessibility concern.

Check it out on Github and let us know how it works for you. Thanks!
https://github.com/filamentgroup/Responsive-Images/tree/cookie-driven#readme

We’ve used CSS3 Media Queries to load different image sizes for different screens. Very simple: techblog.viewbook.com/2011/03/the-css3-media-query-for-dynamically-resizing-elements-on-your-website-for-different-screen-sizes/

@Rien: looks good thanks. I should clarify that this approach is about foreground images, not CSS background images, but for backgrounds we agree: media queries work well :)

@Scott: Indeed that’s why we used background images. And we wanted to make sure the images did not scale themselves, but that bigger or smaller images are loaded based on screen size. Thanks!

Does this technique only switch the image on page load, or also do so if the browser is resized?

For instance, if I open a page on a desktop, but with the browser window very narrow, which image is loaded and does that change as I resize the window?

How is this better than dynamically changing the path to images that need to be optimized:

Use JS to dynamically replace image path with say /images/small, /images/medium, /images/large based on screen size.

The default image is just a 1px placeholder.

No need for .htaccess or inserting/removing BASE element.

@Rien - using background is not good for content images. For example what is a desktop user wants to print and article with images?

Ahh - found the answer to my question in your reply to Craig’s PHP approach:

“The explanation of our article doesn’t quite describe the reasoning for particular approach we took, which is providing a meaningful mobile-optimized image in the HTML, and enhancing it on larger screens without requesting both image sizes. By removing the .htaccess and the JS-generated base element from our technique, it’s impossible to serve a mobile-friendly image in the markup from the start while ensuring larger screen users do not download both image sizes (because JS alone can not prevent that first request from going out to the server). This point is critical to the approach. Simply defaulting to an empty image in the HTML means users on many feature phones (or any browser with JavaScript unavailable or disabled, and search engines as well) will receive no image at all.”

Great idea! The folder seems unnecessary. Can’t the htaccess rewrite simply look for file calls which have “.r.” in them and manipulate those?

Really nice article, only just getting onto the responsive web design band wagon and I’ve come up a jQuery & PHP solution to image resizing which works quite well:
www.jamesfairhurst.co.uk/posts/view/responsive_images_with_php_and_jquery/

Would love to hear what you think.

Many mobile/handheld guidelines stress including explicit and on <IMG, so underpowered layout engines don’t have to deal with changing their layout every time an image’s real size is discovered. No “Responsive Images” solutions (including this one) I’ve seen supply the and . Am I not fully understanding something that should be obvious? Or are the mobile/handheld guidelines I’ve seen all a bit out of date and no longer to be taken seriously? Or is this still a problem in search of a solution? Or...?

Hey Chuck,
I see that advice a lot in performance guidelines too, and I’m sure it does provide a small performance gain. Unfortunately, if you’re scaling your images fluidly, the benefits of providing the width and height attrs would be lost anyway, since the browser will need to calculate its dimensions depending on its parent element when it renders the page. Also, the height attribute gets in the way of allowing an image to scale proportionally as it width increases and decreases.

It’s always game of tradeoffs, I suppose. We think the benefits of images that scale fluidly are worth it in many cases. Thanks! :)

Chuck, the original justification for those guidelines (such as the W3C Mobile Best Practices) was to limit the need for the browser to reflow its layout as it was loading resources - since it can plan around the bounding box of the images as soon as the markup arrives.

With a high latency network and a slow-rendering mobile browser, the effect of the page reflowing for several seconds after the markup has rendered can be very painful and obvious.

Nevertheless, constraining width and height in markup is obviously inappropriate for sites which flow and react to screen size. Since designers are increasingly targeting better performing mobile browsers on faster networks with these techniques, some of the original best practices need no longer be so rote.

However, if you were building a site or app carefully targeted to a particular screen size (or were adapting the site on the server side, where you have a chance to influence the markup responsively too), one might continue to consider adding those attributes. Although very valid, that sort of prescription is anathema to the techniques being discussed here.

thank ypu adimin