How to make your web content look stunning on the iPhone 4′s new Retina display
The iPhone 4's Retina display really does change everything. Learn how to take advantage of it in your web pages and hybrid apps.
The moment you first lay eyes on the iPhone 4's new Retina display, you are ruined. No other display will ever make you happy. Not unless it, too, is a Retina display. You start seeing pixels everywhere. My beloved MacBook Pro's screen? Pixels. The iPad I bought a few months ago and couldn't leave aside? Pixels.
Retina changes everything
The iPhone 4 really does change everything again and not just for phones. By introducing the Retina display, Apple has just changed the rules of the game. Make no mistake, this is as fundamental a shift as the move from black and white to color TV. I now want Retina displays on my next iPad and my next MacBook Pro (and will happily pay a premium for it). Whether or not Apple has the technology to meet the expectations it has now created with the Retina display on its other products is another issue (i.e., does the technology exist to manufacture a 326ppi 15" retina display for a MacBook Pro?)
With the introduction of the Retina display, Apple has guaranteed the following three things:
- Vectors will play a central role in any graphic production pipeline.
- You basically have to design liquid interfaces (and interface elements) for your apps.
- You won't be able to get away with the levels of image compression you've been using so far.
Basically, if you want your applications and web sites to look beautiful on the iPhone 4's new retina screen, you're going to have to create high-resolution versions of your bitmaps and/or use vectors. Resolution independence is here today and it is here to stay.
What about images in web pages?
While version 4 of the iPhone SDK handles much of the hassle of working with two versions of every bitmap for you by automatically loading the right image if you adhere to the simple naming convention of adding @2x to the ends of your image names, no such automagic handling of images exists for images in web pages. I'd been meaning to look into this since I got my iPhone 4 last week and was happy to see that Walt Dickinson beat me to it with his article on Targeting the iPhone 4 Retina Display with CSS3 Media Queries in which he draws on Dave Hyatt's post on high DPI web sites, John Gruber's Why 960x640 post, and the Safari Web Content Guide to suggest the use of device-pixel-ratio CSS3 media query to serve high-resolution images to devices with high-DPI screens:
<link rel="stylesheet" type="text/css" href="/css/retina.css" media="only screen and (-webkit-min-device-pixel-ratio: 2)" />
Then, in the Retina-specific CSS, he loads in 32x32 icons as background images and specifies their dimensions in CSS pixels as 16x16 using the background-size CSS property.
Demo
I put together a quick demo using the same technique that you can test out. It uses the lovely Smashing Royal Icon Set by Artua.com to embed 64x64 and 128x128 actual pixel size icons for display at 64x64 CSS pixel size.
Download the source (.zip; 74KB).
CSS media queries and background images are all well and good, but what about other visual assets such as images embedded on a web site via the img tag? Or videos?
A call for native browser support for high-DPI image and video substitution
I'd like to suggest that browsers adopt the same naming convention that Cocoa Touch uses to find and load high-DPI versions of image and video assets. That is, if I embed an image using the following code…
<img src="flower.jpg" alt="A beautiful rose">
… it should load in flower.jpg when the device-pixel-ratio is 1 but it should attempt to find an image called flower@2x.jpg at the same relative path if device-pixel-ratio is 2 (and so on, for higher pixel-ratios), falling back to the original graphic if it can't find a high-resolution version.
(And the same convention could be used to load video assets.)
Update: Magne Andersson pointed out in the comments (and I agree) that sending two requests for every image asset would not be ideal. However, it would be easy to work around this by introducing a new HTML meta tag that tells the browser whether or not high-resolution images are available. The browser then only tries to load high-resolution images if the meta tag is present and if it detects that it is running on a high-DPI screen.
How to optimize for high-DPI screens today
Since browsers do not currently have this sort of automatic support for loading high-resolution versions of image and video assets, how can we detect that the site is being displayed on a high-DPI screen and load in high-resolution assets? The obvious way is to use a combination of CSS media queries and JavaScript:
- Use the
device-pixel-ratioCSS query to load in a high-DPI CSS file, - Set some CSS property to a unique value (to use as a flag),
- Check that value in JavaScript and substitute high-resolution image/video assets accordingly.
Don't forget about SVG
SVG has been the unloved step-child of the web ever since I can remember. However, it has really begun interest me now that we're moving to creating resolution-independent designs. (That's why I'm so happy that I have the chance to catch Doug Schepers's talk on SVG at tonight's SkillSwap after missing it during WebDirections @media.) If you, too, have been ignoring it, now might be a good time to take another look.
Why native iPhone app developers should care
Most native iPhone applications are – to some degree – hybrid apps and use the UIWebView WebKit control to embed HTML, CSS, and JavaScript content. Some native apps – such as those wrapped by PhoneGap, are almost entirely created with web technologies. Regardless of where on this spectrum your app falls, you will probably find yourself having to support high-DPI images in web content. Not only that, but UIWebView renders SVG so you could consider using it to keep parts of your interface as vectors without having to write custom drawing code.
The iPhone 4's Retina display really does change everything. The sooner you start thinking about (and practicing) resolution-independent design, the sooner you can start to take advantage of this beautiful new screen and the other high-DPI screens that will, no doubt, be following its lead.
The How to make your web content look stunning on the iPhone 4′s new Retina display article by Aral Balkan, unless otherwise expressly stated, is licensed under a Creative Commons Attribution-Noncommercial 2.0 UK: England License.
Good article. It makes me want an iPhone 4, even more.
Still, I don’t think you’ve thought through your “call for native browser support for high-DPI image and video substitution”. As I understand it, that would mean sending two requests for every image on every site? Wouldn’t that lead to problems with bandwidth for little gain (reminding me of the IE favicon mess)?
I think it is better to, in that case, define a new specification which adds a new attribute and CSS property to the element and elements with background-images respectively. I still don’t think that’s a good idea in the end either, though. There are two solutions that I can think of, currently:
1. Supply the high-quality images under the original name.
2. Use SVG-images.
Now, the second option just won’t work with all images, and the first option also introduces a problem with extra bandwidth usage, if no higher resolution of the image is needed. Still, I think that is the best thing you could do today, and is better than your proposal.
SVG definitely is the way to go. Too sad that all the cool stuff still isn’t implemented in webkit-svg-support: http://webkit.org/projects/svg/status.xml
Native browser support I think is a bit of an overreach. This is a problem that will resolve itself in 2-3 years in the high-end market, and wont take a lot more for mass products either. And yes, until it happens, we can do hacks (saving a bit of bandwidth here and there is a commendable exercise), but I don’t reckon that’s something that need to go into browser codebases.
Look at the lowsrc attribute of the <img> tag, which tried to solve a similar problem years ago. Not even IE8 supports it anymore!
Hey Magne,
Thank you for your comment. You’re right, two requests for one image would not be good. You could introduce a new meta tag, however, that tells the browser whether or not high-resolution images/videos are available. That should solve the issue you have with it. If the meta tag doesn’t exist, the browser loads pages as normal. If it does exist, it loads high-resolution images when it detects a high DPI screen. Does that solve the issue you had with the automagical approach?
Brilliant post! I totally agree with the sentiment about the macbook pro screen idea however the problem for designers will be that when designing we are not using the same technology as the end users are using to view our creations and thus as we are not seeing a true representation of what the user will see they may suffer in the long run.
Cheers,
@Prydie
Indeed it does. If it actually gets implemented, I hope it gets an “unofficial” specification along with the first implementation, so that we won’t have to define multiple new meta tags.
By the way, I got to compliment you on your design. I haven’t seen a blog with the comments on it’s side before, but it looks really good (although I didn’t realized that they were there for a while after clicking the submit button).
Thanks for this – I’m sure I’ll be able to use it in some future projects. Very helpful.
Hi, really forward-thinking about liquid interfaces. I have been thinking along this line for years, what with the increasing variety of screen resolutions. And it’s part of the reason why I think HTML + CSS + JavaScript + JQuery is the way of the future. I think most web developers do. Flash is antiquated and should stick to animation and video. I guess that’s also the reason why we’re seeing much less flash sites nowadays.
Thanks for posting this well written article – this will come in handy!
The only problem with this line of thinking is that Google for sure, and possibly other major search engines, are now taking page / load speed into account for search rankings. Updating graphics to come in line with the Retina display will cause a significant increase in the size of what is being loaded on pages. Granted SVG has the potential to solve this problem with vectors being able to scale, but overall this could be a problem in other ways than just the ones that your eyes can see.
This is an insightful article, thanks for the detail… and the iPhone 4 has only been out for a week! Props for getting this together in such a short time.
[...] iPhone 4’s new Retina display June 30, 2010, 4:30 pm Filed under: Uncategorized Cool link: Aral Balkan · How to make your web content look stunning on the iPhone 4’s new Retina display Leave a Comment Leave a Comment so far Leave a comment RSS feed for comments on this post. [...]
A very similar approach to images being scalable came to me recently, as fonts and generally all CSS mark up are scalable why can’t we have images produced from say a pixel size of 100px x 100px and optimise that very same image to scale up to 400px x 400 px to accomodate various zoom levels. More testing involved but a far better experience for the user.
I’m not entirely bright when it comes to display technology, however, my Android phone has a screen with 240dpi. This should mean that newer Android consumers can benefit from this technique also (correct?).
Unfortunatly, the Android browser isn’t meeting the CSS3 device-pixel-ratio media query.
I’ve removed that query from the page and tested myself and can notice a difference, however I wonder if it is just because the browser has more information available, and can do a better job of dithering, or if this is indeed the same technology in effect.
The idea of a browser hammering my site with 404 errors seeking high resolution graphics when in most cases they will not be available seems like… not a good idea. Not to mention the client slowdown as they make double the requests and have to wait for 404 errors to return. Ideally I suspect that the browser should send this capability to the server in the headers (maybe as part of the user agent?) and the functionality should be implemented server-side explicitly, when higher quality assets are available.
The irony here is that Flash – being a vector animation format – would be well suited to delivering high DPI content that scales down well.
Actually you can reduce the number of HTTP requests by putting the media-specific CSS declarations in your main stylesheet. You would use the @media rule in your CSS:
/* All media types */
.someclass {…}
/* Specific media type */
@media … {
.someclass {…}
}
It makes your main CSS a bit cluttered, but you avoid mistakes such as modifying the main styles drastically and not updating the media-type specific styles.
This is what i use for print styles, and simple mobile styles.
Great article.
I was searching for this kind of explanations.
This article perfectly brought me what I was looking for.
Thanks a lot.
Couldn’t you make this more of a backend issue? Currently, to deliver device appropriate content to mobile users there generally has to be some kind of sniffer figuring what browser is making the request e.g IE 7, Opera, or Safari on an iPhone. The browser is recognized by it’s user agent code – wouldn’t it be simpler to just recognize what browser is making the request and send them to the appropriate version of the site? I guess this assumes that there would be new versions of the browsers created for devices with a retina display but this seems like a given to me.
just a thought
Chris
P.S. Great article BTW
Interesting article, I can see the need for this for future computer/iPad high DPI displays but with the iPhone unless you are zooming in far to a webpage people are not going to notice the high resolution images. Also people browsing on 3g or worse are probably not going to appreciate having to download higher resolution images. So I would hope developers do not implement some of the ideas in the article for iPhone users but for larger & high DPI displays I can see the advantages.
Great article, and lots of food for thought.
However, META tags are never the solution to a problem. There are already content negotiation solutions where the same URL returns a different resource depending on what the client is willing to accept.
Currently these use the Accept-Language, -Charset and -Encoding headers but since these are text-specific there’s no reason there shouldn’t be an image-specific Accept-Pixel-Ratio (or similar) header for this purpose.
The biggest problem is that people have tended to ignore content-negotiation because it generally has to be set up away from the content of the site, which isn’t ideal in a lot of cases. However, with device independence as a goal, it’s certainly one of the cleanest ways to approach solving the problem
Excellent article Aral! Hi-DPI is definitely a huge new consideration when developing sites and apps.
Wow, I’m really excited to experience this new wave of HD resolutions and I figured it was just a matter of time that we’d have to develop resolution in dependent layouts.
I’m working on a PhoneGap app right now, that uses the Google Maps API v3 — and Its been “zooming” the layout on my iPhone 4. I noticed that the JS map underperforms on the iPhone 4 compared to my coworker’s iPhone 3GS. If I were to go ahead and make a resolution independent design, GMaps doesn’t have support for the higher res display. The map will have the 4 labels that switch between map, satellite, hybrid, etc. I’m going to see if I can find those labels and do my own little CSS hack on it, we’ll see.
Great stuff, Aral! Thanks a bunch!
Cool, thanks. Also see this PSD icon template which may be useful:
http://mrgan.tumblr.com/post/708404794/ios-app-icon-sizes
Great article. I share your wishes in having an iPad with a retina display, and add a front facing cam to it. I believe the technology is present to make it happen, but the pricing would not be feasible.
With the new data plans i’m sure carriers will appreciate the data charges making web pages 4x the size will bring.
Little known fact: HTML img tag already has resolution swap image substitution attributes: src and lowsrc.
[...] 14) How to make your web content look stunning on the iPhone 4’s new Retina display [...]
“The iPhone 4 really does change everything”
Or, with levity: it really does change ONE thing.
Hi everyone. I’ve been hearing a lot about tablets lately and you mentioned that you’ve bought an ipad lately. There are so many to choose from, but they are also very expensive. You sound like you know a lot about tablets, so maybe you can help me out. Why should I spend a lot of money buying a tablet from Apple or HP, when instead I could just reach into my toilet bowl and grab something hand-held that’s just as shitty, but at a very small fraction of the cost?
Cheers!
There’s actually a great way of achieving automatic loading of double-resolution images with existing browsers and backend technologies.
Upon session start use JavaScript or a roundtrip to the server using the -webkit-min-device-pixel-ratio directive to issue a Cookie on the client indicating that the client has double- (or n-) pixel ratio. Using Apache or any other web server that has rewrite-capabilities create a rewrite rule for all *.jpg, *.gif, …, requests that is conditional upon the existance of that specific cookie and the existense of a @2x version of the requested media.
@Gareth I agree with you completely. Content Negotiation has already solved this problem and should be used as the solution for multiple resolution image resources.
Perhaps an Accept-Display header or something along those lines. Using content negotiation, we’d also get caching for free using the Vary header.
Just another case where looking at the web in a RESTful way yields cleaner solutions. (2 images of varying resolutions are actually 2 separate Representations of the same Resource and thus should be accessible via the same URI)
[...] Aral Balkan: How to make your web content look stunning on the iPhone 4’s new Retina Display [...]
How totally true. Thanks – we need more people doing stuff on this topic .. and for another reason besides dpi… and that is ZOOM. When you zoom you suffer from the smoothing code in the device, and the resolution of the art. Unfortunately, setting 300 dpi into a png and expecting it will zoom any better than the 72dpi png .. is not going to work. However.. there is a way that does work
make your image 2x bigger ( exactly 2x ) and then set the display scale to 50% – so an image 1000 pixels wide is width=500.
works the same in flash also, and you can tinker with compression around 80-90% and get rather good outcomes.
this helps with fullscreen where 1024 to 2560 may be the users pixelspace also.
see this http://w.ctndigital.com?page=27 and resize your browser.
really helps with ipad and iphone also. but there you swap css files and set the 50% differently. I am tinkering now with my droid incredible on this.
Your site rocks and i hope we make a riot of this pixel problem so that all browser coders tend to it, and in the way you identified…. is perfect.
Thanks for the great article! I’d love to know if there’s any way to use inline high-DPI images the same way, rather than relying purely on CSS. I’ve been optimizing my online art gallery for the standard iPhone and iPhone 4 and not having to rely purely on CSS would drastically cut down my work load. Maybe there’s a JavaScript file somewhere that replaces these? If you have any feedback, I’d greatly appreciate it! Thanks again.
Jeffrey Bennett
I know this is not the ideal process but a trick that I have been using is to update all my images to twice the resolution of the original images intended for iphone 3 and other platforms, and then specify the width and height of the images as if they were to be displayed on iphone 3.
Since Safari default to 320 viewport on iPhone 4 for backward compatibility, I did not have to change anything on my website other than specifying the dimensions for the images, and since these dimensions are defined to be how the pages were originally designed for iPhone 3, all stylesheets still work perfectly.
For example. If an image was originally 200 x 200. I now go create another same image but at a dimension 400 x 400.
Then, in the HTML, I put in:
It is just a bandage quickfix. It buys me sometime to work on the website for a longer term solution, but yet, all my users get to enjoy the high resolution on their iPhone 4 today!
Dear Aral, thank you very, very, very much for your article. We are currently updating our App for iPhone 4 and your advices have been very, very helpful. I am really glad that I discovered your article.
An important advice: It’s better to use the Webkit-specific CSS property “-webkit-background-size” instead of the generel “background-size” because iOS 3.1 can’t interpret the latter.
Once again mac fans have no clue what they are talking about. It’s troubling.
For the jQuery users:
http://troymcilvena.com/post/998277515/jquery-retina
For MooTools users:
http://mootools.net/forge/p/mooretina
It isn’t the start of resolution independence, it’s the end! Once displays hit 300dpi, there is no further to go. That’s the resolution magazines are produced at. Once 300dpi is commonplace, it will be the standard resolution forever.
Thanks for this article Aral. Exactly what I needed for the mobile website I’m building.
[...] How to make your web content look stunning on the iPhone 4’s new Retina display by Aral Balkan outlines the high-level impact of the Retina Display on Web design & development. [...]
Thanks for this little guide. I just stumbled over some problems with a small embedded webserver that fracked up the SVG i used for menu icons and which worked great on the Retina – when not using this embedded server. I can’t re-engineer the problem, but I just did it your ways – and it just works. :)
Would make sense for the time being for Safari on an iPhone 4 to do the image swap in exactly the same way it would for the native apps.
Until there’s a slicker solution that works with all ‘future’ hi-res displays.
thanks! This helped me out greatly
Sorry, late to the game here, but I was just testing some browser behaviour relating to this and stumbled across your post. My question: for web content, why bother with the specific media query stuff to serve higher-dpi images only to high-dpi devices? Why not just specify the high-dpi versions in all cases, and let browsers on lower-dpi devices render the graphic down? Is it purely to have absolute pixel-perfect control over how things look on low-dpi devices? And not just with CSS, also good old image elements…
Hey there!
Thanks for the excellent post, helped me out with a load of situations, but there’s one thing that isn’t working for me.
You stated that in the “A call for native browser support for high-DPI image and video substitution” an image would be replaced with the “@2x” version of it, if the image was viewed in a Retina display, but for me it’s not working.
I currently have a navigation menu, with icons next to the items, I have created two copies of the image, one named “home.png” and the Retina one “home@2x.png”, yet when I view this on my iPod Touch 4G, it displays the low resolution version.
Thanks!
Ok, the new iPad is on the way, how about an updated article?
Thanks…this is great stuff.
Just one problem: In Safari on the iPad, trying to get a 1500 pixel wide image to render 1:1 with the iPad’s hardware pixels, it not easy. The result is that the image quality is reduced as the iPad scales the image up to 1536 pixels in portrait, or more in landscape. Even 36 pixels of change results in a noticeably softer image as a result of the scaling.
The benefits of the retina display are therefore lost. For general web browsing this doesn’t matter, but for people who are making photo galleries and care about the quality of their hi-res website galleries, this is really a disappointing situation.
The only way photos can EVER look pin-sharp on the retina display, is when they are presented without any scaling, which is not easy to achieve for both portrait and horizontal orientation at once.
Fascinating blog! Is your theme custom made or did you
download it from somewhere? A design like yours with a few
simple tweeks would really make my blog stand out.
Please let me know where you got your design. Cheers