Like the James T. Kirk character in Start Trek, I don’t believe in no-win scenarios.
That is until I come across the idea of adaptive images in responsive web design.
In Mat “Wilto” Marquis’article, he reviews the trials behind the Boston Globe redesign project to get images served in an adaptive manner — meaning that the proper, optimized image is delivered to the appropriate device based on the following factors:
- screen resolution
- bandwidth
- browser window width
The problem with trying to determine the best image to send to the browser is these kinds of factors can be independent of each other.
And that wherein lies the problem: knowing the value of one item, like screen resolution, doesn’t mean you get the full picture of the user’s browser experience.
Tiny Displays
First, the iPhone 4 introduced the notion of retina display (640×960 resolution at 326 pip). Before the iPhone 4, one might have gotten away with letting just the browser width. That roughly translate to the axiom:
The smaller the screen, the slower your internet connection.
However, that’s not the case as displays are becoming great at compacting lots of image data in a small screen.
Thought Experiment
Let’s think of this problem in another way with the following thought experiment:
The iPad 3 that is rumored to come out in the Spring of 2012 will have retina display that rivals most desktop displays and will no doubt have 3G models.
Also, since the screen of the iPad is going to be presumably the same dimensions as the iPad 2, the browser “width” is going to be the same.
So, realizing that the browser width isn’t helpful and if a site visitor is surfing the web on an iPad 3 with 3G, which image do you deliver on your site?
- Do you deliver the low-resolution, mobile friendly version?
- Or do you let the iPad 3 have the larger version, but with the longer download time?
Measure a Few Additional Times, Cut a Couple More
If you are building a complex site the size of the Boston Globe, you can follow their lead.
The best solution that’s agreed by most current solutions is to set “mobile friendly” images as the value for SRC attributes for image elements.
Then set the URL to the high-resolution image as a value an HTML5 DATA- attribute.
<img src="images/mobile-size.jpg" data-fullsrc="images/desktop-size.jpg"/>Then setting screen-size in a browser cookie, you can use server-side requests to deliver the appropriate image to the right browser.
A variation of the solution called, aptly, Adaptive Images in HTML aims to keep HTML pure while utilizing PHP, JavaScript and modying .htaccess files.
If you aren’t into hacking .htaccess files to serve image files, you can look into a cloud-based service for the solution for some help.
The folks closest to this at Sencha have just a solution at src.sencha.io for scaling images, but not for replacing high-resolution images for the site visitor when it’s appropriate.
If the service added a feature of checking and delivering the appropriate image in addition to context aware images, I think the folks at Sencha would have a great hit on their hands.
And they might have another revenue stream along the same lines as people that rent out web fonts.
Back to Old School
If you are working on a smaller scale web site, I humbly recommend a solution I’ve been working on called HiSRC.
It’s a twist on the old school LOWSRC IMG attribute, which would render a lower file size image first while a larger file size image would appears in its place later.
Back to the future, we set in the markup and leave the lower file size image.
However, if the HiSRC plugin detects fast network or high resolution, then a high resolution image takes the image’s place.
The browser loads the low-resolution image first with an old-fashion IMG SRC attribute.
Then the HiSRC jQuery plugin checks the resolution of the browser.
If the browser resolution is wider than the default 640 pixels width, then the plugin overwrites the low-resolution image for the higher resolution image.
Whereas, if mobile bandwidth is detected (like 3G), the low-resolutions stay in place thanks to the new navigator.connection first seen in Android 2.2.
The downside is that site visitors with higher resolutions get the tax or burden of having to download two images instead of one.
For small projects or small scale projects where PHP or using .htaccess isn’t possible or too much of a burden, then I think that’s a fair price to pay until the future catches up with us.
Escape with All Alive (Except the Klingons)
Of course, there are ways to workaround the issue of delivering mobile friendly images without having a web builder be concerned about their visitor’s browser window, resolution or bandwidth.
One way is to place images in background of HTML elements and set background-size: auto; to have them scale as the element resizes. As the container element expands, so does the image in the background.
Another way is to work with Scable Vector Graphics (SVG). SVG has made great leaps in browser support. In fact, in modern browsers support inline SVG images natively. Why we aren’t talking more about SVG these days I don’t know as it seems like manfiect desitny for responsive web design.
If you want to wait a bit longer, there might be support for a “new” image format that serves up multiple resolution. This has already been addressed in the Flashpix image format, but has yet to be adopted for web delivery.
NOTE: For more on adaptive images and responsive web design, check out my new podcast The Non-Breaking Space Show with David McFarland and Chris Enns where we interview the one-and-only Ethan Marcotte.