http://benfrain.com/how-to-serve-high-resolution-website-images-for-retina-displays-new-ipadiphone4/

About

This article covers how to serve high resolution images on your website for users of high resolution ‘retina’ device screens.

Introduction

When it comes to talking ‘mobile’ – I often read Luke Wroblewski’s blog.

Yesterday, he shared the following summary of info from Apple’s new iPad launch:

A total of 315 million iOS devices have been sold with 62 million sold the last quarter alone.
76% of Apple’s revenue in Q42011 came from the iOS product lines: iPod, iPhone, and iPad
Apple now has 362 retail stores worldwide.
Over 25 billion app downloads since Apple introduced the App Store.
There are now over 100 million customers on iCloud.
Apple sold 15.5 million iPads last quarter alone. That’s more iPads sold in the last quarter alone than any PC manufacturer sold in their entire line. The iPad is just 2 years old.
200k apps have been custom built for the iPad.

It doesn’t take a genius to appreciate that if you aren’t designing and building websites today with the gamut of available devices (mobile, tablet, laptop, portable game station, desktop etc.) in mind you’re very quickly going to fall behind.

One feature of the newer iOS devices I’m particularly excited about is the ‘Retina’ displays. Whilst the ‘new iPad’ (also known variously until this point as third generation iPad, iPad3, iPadHD and other monikers) has a 2048-by-1536-pixel resolution at 264 pixels per inch (ppi) screen, the iPhone 4 and iPhone 4S have an ever higher resolution screen: 960-by-640-pixel resolution at 326 ppi. If you have one of these devices you’ll know that images and text look beautiful on them.

Before long, my feeling is that our desktop and laptop systems will follow suit. After all, we are all vociferous consumers of online content. Whilst previous generations consumed their content through printed media, that until now has enjoyed a greater resolution than any screen (no substitute for the power of eyeballs…yet), there now exists the possibility for our digital devices (handheld, desktop, whatever) to enjoy a level of ppi more akin to print.

When it comes to text, fonts, with their mathematical scalability fare excellently on these higher ppi devices. A good font looks beautiful on a retina display. However, web images, typically exported at 72 dpi (dots per inch, not pixels per inch – I’m not getting into that here), don’t fare quite so well. Here’s how we can fix that.

Media Queries let us target high resolution devices

I cover Media Queries a LOT in my book (blatant plug), and I’m not going over the basics of them here, understanding how they work is essential for serving alternate content on web sites (through CSS) for high resolution screens. Whilst the venerable Dave Hyatt was talking about serving different content to high resoltion screens back in 2006, I’ve read lots of material covering the specifics of the issue since. I’d therefore recommend checking out smarter people than me too: Josh Clark, Aral Balkan, Walt Dickenson to name a few.

In a nutshell, the super smart W3C people who help bring about and ratify new web standards had the foresight to consider high resolution screens. Therefore, when defining Media Queries, we have the capability to target media based upon device pixel ratio. Here’s the media query in the style sheet for this site that handles showing a higher resolution of my logo for iOS devices that support it:

We’ll break that down but first some things to note:

• It’s important to provide a full vendor-prefix stack to future proof these kind of rules.
• If you don’t want to add a full vendor stack, consider implementing Lea Verou’s excellent ‘Prefix free’ JavaScript solution – it’ll add vendor-prefixes as and when needed, preventing vendor-prefix bloat in your CSS.
• I’ve named my ‘high-res’ file using the Apple naming convention (adding @2x to the end) – it’s the way it’s done on iOS app development and I’ve adopted the convention here. When designing web sites, it’s just a handy way for me to see which files are high res and which aren’t.
• As with all media queries, it’s advisable to load/write them after the main styles so that the cascade gives them preferential treatment. If you are using Sass, just use a partial for the media queries and import it at the end of the main style sheet.

So what’s the media query actually doing? First, we’re telling the user agent (the web browser for all intents and purposes) that we want the rule to apply to ALL media (that’s the '@media all' part).
Next, we are stipulating that the rule should apply to all devices with a minimum pixel ratio of 1:1.5 or more – that’s the (-webkit-min-device-pixel-ratio : 1.5) part. Inside we then just stipulate as many CSS rules as we like that should apply to appropriate devices in the normal way.

You can alter this kind of query so that only devices with a pixel ratio of 1:2 are targeted. For example:

In that example, I have omitted the vendor prefix (I mention that just in case you cut and pasted and nothing’s happening).

Resizing the background image

In my main rule for that image (the non-media query rule that serves all non-retina displays) I already have a declaration for resizing the background image with CSS3: background-size: contain;. You’ll need something like that or explicitly state the background size. For example, if the non-retina image is 200px by 200px but the high-resolution image is 400px by 400px, you could do this:

So, the background image for non-retina displays will display at 200px x 200px (assuming the containing element is big enough, otherwise is will be cropped). Then the rule specific for high resolution displays:

Here, although the high-res ‘retina’ image is actually 400px x 400px, our background-size: property allows us to define the size it should display at.

Considerations for using high resolution images

Some obvious considerations: bigger images take longer to download – it’s a dangerous assumption to make but mobile devices may be accessing your content over a cellular service – bigger images will slow the site down. When an image is double the physical size, the KB size is considerably greater. For example, consider that this picture of HRH Queen Elizabeth II is 184KB at standard size (direct link to image at 800 x 584px) and the image double the physical size (direct link to image at 1600 x 1168px) is 694KB. That’s over 3 times as much data. If you do this for all the images on your page, regardless of whether or not users actually have an HD/retina display – the page will be slow for most people, with no discernible increase in quality for them.

Sadly, there are no CSS rules like this we can implement.

At present, it’s necessary to think long and hard about what high res content you want to use in this way.

Want to show high resolution icons for retina displays? Use a font!

We already know that fonts scale brilliantly. If you need to use an icon in your design, don’t use an image, use a font instead. There are a growing number of ‘Icon Fonts’ available that you can implement into a web page using the @font-face rule. Here’s some examples:

nopasd

I actually just typed the letters ‘nopasd’ there and wrapped them in a relevant class (that has the related font defined) and they displayed as a font.

View that on a retina/high-res display and you’ll see it’s beautifully crisp. It can also scale to whatever size you need. Just amend the CSS to suit. For example:

There are other benefits, namely speed – only 1 http request for a raft of icons. I used the technique on this (2012 at the time of writing this ) version of my site and all the navigation and footer icons, plus those on the design and writing pages are a single icon font. If you’re concerned about semantics and don’t want loads of random letters scattered throughout the markup, another option is using the :before or :after pseudo classes. For example, use markup like this:

And then, in the CSS do this:

As span is essentially meaningless from a semantic point of view, it presents the best of both worlds if the icon in question is purely there for aesthetic reasons.

Providing alternate high resolution inline images for retina devices

The above media query based solution works fine and dandy for background images but what about standard img tags added in markup? Sadly, at present there is no ‘normal’ way to do this purely through markup. There are JavaScript solutions (such as this one at Flowz) that are relatively simple to implement. There’s also a jQuery Retina Display plugin to replace inline images for high res counterparts (should they exist). You might be interested to check out how I used that plugin to create a HD/retina toggle for this site for devices that have HD/retina screens. Modernizr may also be able to help with this kind of solution in the future. There are some merge requests/info on the Moderniz Github that look like they’ll help in future iterations.

Adaptive images

Also, if you are happy to serve high resolution images to all high resolution screens (regardless of whether the user actually wants to see and wait for the high-res images to load or not), you can use adaptive-images.com. That lets you upload a single high-res image and then automatically serves alternate sized versions for other breakpoints/screen sizes. It works well with CMS systems and doesn’t require any changes to markup. Basically fit and forget.

Use SVG? Responsive/High Resolution Images through markup?

Scalable Vector Graphics will (if support is good enough) work great for some situations. Sadly many tools, other than say Illustrator, don’t have decent SVG export options (as an example, Fireworks CS5 can export SVG with an add-on – but it doesn’t export allow exporting the SVG as outlines so any fonts that are included as part of the graphic don’t export well). Plus SVG won’t help with photos and the like. However for simple vector images, it’s hard to beat in terms of file sizes. For example, I’ve also added an SVG version of my logo for browsers that support it, rather than the higher res PNG – it looks equally good on retina displays. File size is considerably less: the PNG is 33KB, whilst the SVG file is only 4KB – that’s some difference! So to provide a PNG/JPG/GIF fallback graphic with an SVGZ for the user agents that understand, assuming you’re using Modernizr:

The W3C also has a responsive images community working group that is trying to establish a way of inserting alternate media sources into code. Hopefully, this will bare fruit and there will eventually be a simple way to define different media for different device ranges directly through markup.

Testing different devices

Previously, testing multiple devices required, well… multiple devices. There’s still no substitute for that. But, if, like me, you work with responsive designs most of the time, it’s a bit of a chore to test iterations: pressing refresh on 3 or more devices to see what the latest tweaks did. I’d looked at Weinre but never actually set it up. Thankfully, Adobe Labs have released a GUI version of the system called ‘Adobe Shadow‘. It enables your devices to remain in sync so that when you refresh the browser on one device, it automatically refreshes the page on the other devices too. Furthermore, it enables Firebug/Developer tools style debugging so you can see if the high resolution images are actually working or not.

Your feedback welcomed

I’m hoping this ‘whistle-stop tour’ of providing high resolution images for retina displays was informative. However, I welcome feedback, queries and corrections in the hope of improving this piece in any way.