Menu Search
Jump to the content X X
SmashingConf London Avatar

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf London, dedicated to all things web performance.

Resolution Independence Towards A Retina Web

With the recent announcement and release of the Retina Macbook Pro, Apple has brought double-density screens to all of the product categories in its current lineup, significantly paving the way for the next wave of display standards. While the fourth-generation iPhone gave us a taste of the “non-Retina” Web in 2010, we had to wait for the third-generation iPad to fully realize how fuzzy and outdated our Web graphics and content images are.

In the confines of Apple’s walled garden, popular native apps get updated with Retina graphics in a timely fashion, with the help of a solid SDK and a well-documented transition process. By contrast, the Web is a gargantuan mass whose very open nature makes the transition to higher-density displays slow and painful. In the absence of industry-wide standards to streamline the process, each Web designer and developer is left to ensure that their users are getting the best experience, regardless of the display they are using.

Further Reading on SmashingMag: Link

Before diving into the nitty gritty, let’s briefly cover some basic notions that are key to understanding the challenges and constraints of designing for multiple display densities.

Device Pixels Link

Device Pixels5

A device pixel (or physical pixel) is the tiniest physical unit in a display. Each and every pixel sets its own color and brightness as instructed by the operating system, while the imperceptible distance between these tiny dots takes care of tricking the eye into perceiving the full image.

Screen density refers to the number of device pixels on a physical surface. It is often measured in pixels per inch (PPI). Apple has coined the marketing term “Retina” for its double-density displays, claiming that the human eye can no longer distinguish individual pixels on the screen from a “natural” viewing distance.

CSS Pixels Link

CSS Pixels6

A CSS pixel is an abstract unit used by browsers to precisely and consistently draw content on Web pages. Generically, CSS pixels are referred to as device-independent pixels (DIPs). On standard-density displays, 1 CSS pixel corresponds to 1 device pixel.

<div height="200" width="300"></div>

This would use 200 × 300 device pixels to be drawn on screen. On a Retina display, the same div would use 400 × 600 device pixels in order to keep the same physical size, resulting in four times more pixels, as shown in the figure below.

Device Pixels In Retina Displays7
On a Retina display, four times as many device pixels are on the same physical surface.

The ratio between device pixels and CSS pixels can be obtained using the following media query and its vendor-specific equivalents:

-webkit-device-pixel-ratio {

Or you can use their future-proof siblings:

-webkit-min-device-pixel-ratio {

In Javascript, window.devicePixelRatio can be used to obtain the same ratio, although browser support is still relatively limited. Both of these techniques will be discussed in depth later in this article.

Bitmap Pixels Link

Bitmap Pixels8

A bitmap pixel is the smallest unit of data in a raster image (PNG, JPG, GIF, etc). Each pixel contains information on how it is to be displayed, including its position in the image’s coordinate system and its color. Some image formats can store additional per-pixel data, such as opacity (which is the alpha channel).

Beside its raster resolution, an image on the Web has an abstract size, defined in CSS pixels. The browser squeezes or stretches the image based on its CSS height or width during the rendering process.

When a raster image is displayed at full size on a standard-density display, 1 bitmap pixel corresponds to 1 device pixel, resulting in a full-fidelity representation. Because a bitmap pixel can’t be further divided, it gets multiplied by four on Retina displays to preserve the same physical size of the image, losing detail along the way.

Bitmap Pixels On Retina Displays9
Each bitmap pixel gets multiplied by four to fill the same physical surface on a Retina display.

The Tool Chest Link

Even though we are still in the early stages of this major shift, several approaches to optimizing Web graphics for Retina displays have sprung up, and more are popping up as we speak. Each method makes some degree of compromise between performance, ease of implementation and cross-browser support. As such, choosing a tool should be done case by case, taking into account both quantitative and qualitative factors.

HTML And CSS Sizing Link

The most straightforward way to serve Retina-ready Web graphics is to halve the size of your raster assets using CSS or HTML, either manually or programatically. For instance, to serve a 200 × 300-pixel image (remember, those are CSS pixels), you would upload an image with a bitmap resolution of 400 × 600 pixels to your server, then shrink it by exactly 50% using CSS properties or HTML attributes. On a standard-resolution display, the result would be an image rendered with four times fewer pixels than its full bitmap size — a process commonly referred to as downsampling.

How downsampling works10
A CSS-sized image gets its dimensions halved during the rendering process.

Because the same image would use four times as many physical pixels on a Retina screen, every physical pixel ends up matching exactly 1 bitmap pixel, allowing the image to render at full fidelity once again.

How HTML sizing works11
CSS-sized images regain their full-detail glory on Retina displays.

There are several ways to achieve this:

Using HTML Link

The easiest way to apply CSS sizing would be by using the width and height attributes of the img tag:

<img src="example@2x.png" width="200" height="300" />

Please note that, even though specifying height is optional, it allows the browser to reserve the space required for the image before loading it. This prevents the page layout from changing as the image loads.

What to use it for? Single-page websites with few content images.

Using Javascript Link

The same result can also be obtained using Javascript by targeting all Retina-ready content images in the document and halving their sizes. With the help of jQuery, this would look like this:

$(window).load(function() {
  var images = $('img');
    images.each(function(i) {
      $(this).width($(this).width() / 2);

What to use it for? Websites with few content images.

Using CSS (SCSS) Link

If you want to keep all of the presentation code in your CSS files, then the most common technique involves setting the image as the background of another HTML element, usually a div, then specifying its background-size property. You could either set explicit width and height values for the background image or use the contain value if the dimensions of the HTML element are already specified. It is worth noting that the background-size property is not supported in IE 7 or 8.

.image {
  background-image: url(example@2x.png);
  background-size: 200px 300px;
  /* Alternatively background-size: contain; */
  height: 300px;
  width: 200px;

You could also target a :before or :after pseudo-element instead:

.image-container:before {
  background-image: url(example@2x.png);
  background-size: 200px 300px;
  display: block;
  height: 300px;
  width: 200px;

This technique works just as well with CSS sprites, as long as the background-position is specified relatively to the CSS size (200 × 300 pixels in this case):

.icon {
  background-image: url(example@2x.png);
  background-size: 200px 300px;
  height: 25px;
  width: 25px;

  &.trash {
    background-position: 25px 0;

  &.edit {
    background-position: 25px 25px;

When using image sprites, consider any OS-specific limitations.

What to use it for? Websites that make limited use of the background-image property, such as those that rely on a single-image sprite.

HTML and CSS Sizing: Pros Link

  • Easy to implement
  • Cross-browser compatible

HTML and CSS Sizing: Cons Link

  • Non-Retina devices have to download larger assets.
  • Downsampled images might lose some of their sharpness on standard-density screens, depending on the algorithm used.
  • The background-size property is not supported in IE 7 or 8.

Querying Pixel Density Link

Querying Pixel Density12

Perhaps the most popular way to serve Retina-ready graphics on the Web is by querying the device for its pixel density and then serving assets accordingly. This can be done using either CSS or JavaScript.

Using CSS Media Queries Link

As of this writing, almost every major browser vendor has implemented a prefixed variant of device-pixel-ratio and its two siblings, min-device-pixel-ratio and max-device-pixel-ratio. These media queries can be used in conjunction with the background-image property to serve Retina-ready assets to high-density devices:

.icon {
  background-image: url(example.png);
  background-size: 200px 300px;
  height: 300px;
  width: 200px;

@media only screen and (-Webkit-min-device-pixel-ratio: 1.5),
only screen and (-moz-min-device-pixel-ratio: 1.5),
only screen and (-o-min-device-pixel-ratio: 3/2),
only screen and (min-device-pixel-ratio: 1.5) {
  .icon {
    background-image: url(example@2x.png);

By using a ratio of 1.5 instead of 2, you can target other non-Apple devices with the same query.

What to use it for? Any website or app that uses the background-image property for graphic assets. Not suitable for content images.

CSS Querying: Pros Link

  • Devices download only those assets that target them.
  • Cross-browser compatible
  • Pixel-precise control

CSS Querying: Cons Link

  • Tedious to implement, especially on large websites.
  • Displaying content images as backgrounds of other HTML elements is semantically incorrect.

Using Javascript Link

The pixel density of the screen can be queried in Javascript using window.devicePixelRatio, which reports the same value as its CSS counterpart. Once a higher-density screen is identified, you can replace every inline image with its Retina counterpart:

  if (window.devicePixelRatio > 1) {
    var lowresImages = $('img');

    images.each(function(i) {
      var lowres = $(this).attr('src');
      var highres = lowres.replace(".", "@2x.");
      $(this).attr('src', highres);

Retina.js13 is a Javascript plugin that implements roughly the same technique as described above, with some additional features, such as skipping external images and skipping internal images with no @2x counterparts.

Lastly, it is worth noting that devicePixelRatio is not entirely cross-browser compatible14.

What to use it for? Any website with content images, such as landing pages and blogs.

Javascript Querying: Pros Link

  • Easy to implement
  • Non-Retina devices do not download large assets.
  • Pixel-precise control

Javascript Querying: Cons Link

  • Retina devices have to download both standard- and high-resolution images.
  • The image-swapping effect is visible on Retina devices.
  • Does not work on some popular browsers (such as IE and Firefox).

Scalable Vector Graphics Link

Scalable Vector Graphics15

Regardless of the method used, raster images remain inherently constrained by their bitmap resolution; they were never meant to be infinitely scalable. This is where vector graphics have the advantage, being a future-proof way to “Retinize” your Web graphics.

As of this writing, the vector XML-based SVG format has cross-browser support16 of more than 70% and can be used in several ways on the Web. SVG images can be easily created in and exported from a number of vector-graphic editors, such as Adobe Illustrator and free alternatives such as Inkscape17.

As far as Web design goes, the most straightforward way to use SVG assets is with the HTML img tag or with the CSS background-image and content:url() properties.

<img src="example.svg" width="200" height="300" />

In the example above, a single SVG image can be used as a universal asset, scaling infinitely up or down as required. This not only saves precious bandwidth (most SVG files tend to be smaller in size than standard-resolution PNGs), but also makes your graphic assets much easier to maintain. The same would apply if used in CSS:

/* Using background-image */

.image {
  background-image: url(example.svg);
  background-size: 200px 300px;
  height: 200px;
  width: 300px;

/* Using content:url() */

.image-container:before {
  content: url(example.svg);
  /* width and height do not work with content:url() */

If you have to support IE 7 or 8 or Android 2.x, then you will need a fallback solution that swaps SVG images with their PNG counterparts. This can be easily done with Modernizr18:

.image {
  background-image: url(example.png);
  background-size: 200px 300px;

.svg {
  .image {
    background-image: url(example.svg);

For best cross-browser results and to avoid some rasterization headaches19 in Firefox and Opera, make each SVG image at least the size of its parent HTML element.

In HTML, you can implement a similar fallback solution by adding a custom data attribute to your img tag:

<img src="example.svg" data-png-fallback="example.png" />

Then, handle the rest with jQuery and Modernizr:

  if(!Modernizr.svg) {
    var images = $('img[data-png-fallback]');
    images.each(function(i) {
      $(this).attr('src', $(this).data('png-fallback'));

This HTML and JavaScript route, however, would not prevent browsers with no SVG support from downloading the SVG assets.

What to use it for? Any website or app. Suitable for icons, logos and simple vector illustrations.

SVG: Pros Link

  • One universal asset for all devices
  • Easy to maintain
  • Future-proof: infinitely scalable vector graphics

SVG: Cons Link

  • No pixel precision due to anti-aliasing
  • Unsuitable for complex graphics due to large file sizes
  • No native support in IE 7 and 8 or early Android versions

Icon Fonts Link

Icon Fonts20

Popularized by Twitter’s Bootstrap21, the technique of using @font-face with icon-based fonts has garnered a following of its own as a resolution-independent alternative to bitmap icons. The technique consists of using a custom Web font that replaces the alphabet with monochrome glyphs, which can be styled using CSS, just like any other text on the website.

There is no shortage22 of comprehensive, good-quality icon fonts that would cover most of your needs. That being said, importing a large font in half a dozen formats only to use a small subset of the icons is a bad idea. Consider building your own custom font with free tools such as Fontello23, Font Builder24 or even Inkscape25.

The most common way to use icon fonts on websites is by assigning an .icon or .glyph class to a particular HTML element — most often a <span> or an <i> — and then using the letter corresponding to the desired icon as its content:

<span class="icon">a</span>

After having imported your custom font using @font-face, you would declare it:

.icon {
  font-family: 'My Icon Font';

Another technique consists of using the :before pseudo-element and the content property, with a unique class for each icon:

<span class="glyph-heart"></span>
[class^="glyph-"]:before {
  font-family: 'My Icon Font';

.glyph-heart:before {
  content: 'h';

What to use it for? Websites or apps with a high number of icons, and for rapid prototyping.

Icon Fonts: Pros Link

  • Future-proof: infinitely scalable glyphs
  • Cross-browser compatible
  • More flexible than graphic assets: can be used in placeholder text and other form elements, etc.

Icon Fonts: Cons Link

  • No pixel precision due to subpixel anti-aliasing
  • Hard to maintain: changing a single icon requires regenerating the whole font.
  • Relies on semantically incorrect markup (unless used with :before or :after pseudo-elements).

Favicons Link

Favicons are getting their fair share of attention, being increasingly used outside of browser chrome as an iconic representation of our websites and apps. To make your favicons Retina-ready, export an .ico file in both 16- and 32-pixel versions. If you are using a Mac, you can create your own .ico files with Apple’s Icon Composer (included in the Graphic Tools in Xcode26) or with Icon Slate27, a paid third-party application.

A Glimpse Of The Future Link

Besides the techniques covered above, several other efforts are being made independently by organizations and individuals alike, not the least of which is Apple’s own -Webkit-image-set, introduced28 last spring. This proposal allows for29 multiple variants of the same image to be provided in one CSS declaration:

.image {
  background-image: -Webkit-image-set(url(example.png) 1x, url(example@2x.png) 2x);
  background-size: 200px 300px;

This technique does not, however, cover images inside img tags, and it is Webkit-only as of this writing.

Another notable effort is Scott Jehl’s Picturefill30, an HTML and Javascript solution that makes heavy use of data attributes and media queries to serve different images in different media contexts.

<div data-picture>
     <div data-src="example.png"></div>
     <div data-src="example@2x.png" data-media="(min-device-pixel-ratio: 1.5)"></div>

  <!-- Fallback content for non-JS browsers -->
    <img src="example.png" >

Even if the markup puts you off, it is a good cross-browser solution to consider if you are dealing with few content images.

Last but not least, the ambitious picture element proposal31 aims to bring responsive images to the Web using a markup-only approach for multiple image sources, coupled with media queries that route each device to the right asset.

Closing Words Link

Like other major shifts32 the Web is currently undergoing, attaining resolution independence will be a long journey. As Web designers and developers, either we can sit down and wait passively for a convention to be standardized, or we can immediately start offering a pleasurable viewing experience to our users. Let’s get to work.


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. 13
  14. 14
  15. 15
  16. 16
  17. 17
  18. 18
  19. 19
  20. 20
  21. 21
  22. 22
  23. 23
  24. 24
  25. 25
  26. 26
  27. 27
  28. 28
  29. 29
  30. 30
  31. 31
  32. 32

↑ Back to top Tweet itShare on Facebook

Reda Lemeden (@kaishin) is a Web and interface designer at thoughtbot, Inc. He enjoys conceptualizing problems and solving them using technology and design. He curates Learn Swift and maintains Bourbon Neat.

  1. 1

    Good in-depth article. I’m especially keen to try the retina sprite option with LESS/SCSS discussed in a previous post, seems like a good efficient way of setting it up.

  2. 2

    Seriously, you want to put in all your effort to re-design n entire site just because some bastard minority community owns a retina Macbook Pro?

    • 3

      Considering that the “bastard minority community” is also, today, the most affluent one you have, and tomorrow will probably be a “bastard majority community” one way or the other… yes, you’ll want to.

    • 4

      While David’s message may be somewhat flame worthy I do see his point. Although I don’t expect standard resolution displays to remain the “standard” for long. I think the continued use of Retina is misleading, and only starts debates between mac fans and detractors, what we’re really talking about is “high resolution displays” regardless or manufacturer or pixel density. (Android is 1.5 density Apple at 2).

      The point is that right now as it stands anyone who owns a device that has higher density is still the minority. This will soon change as mobile devices eclipse Desktops and will only be accelerated once desktops get high resolution displays themselves. (And no this won’t be a MAC only change)

      So I guess I’m trying to say I agree with David in the sense that I’m not rushing to implement this yet. I don’t feel we’ve reached the tipping point where the majority of web users are on HD displays. It’s a cost/benefit decisions from a business perspective. However right now IS the perfect time to read about and study the technology to ready for the HD upgrade which is (inevitably) coming in a year or two.

    • 7

      All monitors will eventually be high resolution like a retina screen. To think that they wont is pretty ignorant to all of tech history. Can’t you see from how TVs have evolved over the years?

    • 8

      This all applies to any device using a higher physical pixel density than the CSS pixel density. That means all of Apple’s “Retina” Devices – iPhone 4, iPhone 4S, 3rd gen iPad and Retina MacBook Pros. Do you still think this applies only to a minority of users?

    • 9


      August 23, 2012 1:48 am

      Hear hear, David! When all displays are poised to move to a higher pixel density, ok, we can start seriously moving to these solutions. For now, I think they should be mused and prepped. But articles the web over are acting like we should already be doing this with full force. And why? Literally because of TWO Apple devices. Sorry, but I’m not putting it yet another set of media queries and doing all of this double-size-then-halve image math crap just for two devices. People like GiacomoL insist Apple users are the most affluent. Pffft. It’s hard for me to agree when they’re demanding to know how high they should jump after Apple tells them to. IMO, this is one of those things were we shouldn’t have to carry the burden (I am starting to think web developers are all masochists who like making the burden of accommodating all tech changes our sole problem). I think the device should fix this, or meet us more than half of the way.

    • 10

      But where Apple leads everyone else will follow. You may not want to change your sites now, but you would be wise to start learning the techniques for when everyone else catches up.

  3. 11

    I can’t help but be a bit annoyed with Apple. A proprietary device level feature that just creates more work for US, and forces the web to respond with hacks and methods to try and deal with it. It’s snotty and aggressive. I’d rather not have down-scaled images on regular displays, (most displays), and WHY would I want 4x the pixel density on a SVG vector based image? Vector images by their very nature have less detail than a quality raster image. Getting 4x the res is pointless. As for the other methods, I’ll have to try them out.

    Good article though. Thanks again Smashing!

    • 12

      I remember trying to design “scalable” and “liquid” webpages more than 10 years ago. It was basically the same problem: on the web, what you emit will be *interpreted* by client devices. Remember how CSS allowed you to send different stylesheets for different devices and different uses (print etc)? This is the same thing, except it touches something CSS spec-authors didn’t think about, so web standards have to catch up.

      Today you have to build some workaround, meanwhile web standards will improve and hopefully you won’t have to rewrite those workarounds once we hit 3x or 4x density.

    • 13

      So, new display tech that actually improves the state of the art is “snotty and aggressive?”

      I never cease to be amazed at those working in a high tech industry who fear & resist progress. I’ve seen the same perspective in the print design and video production worlds as well.

      It’s new opportunities, folks!

  4. 14

    Even if we move every device to higher resolution, it will put a bigger burden on bandwidth costs for both host and visitor. Then when that settles, a higher resolution will come again and we have to this all over again.

    I like the round-up of solutions, but how about this one:

    Use your images as they are, at 72dpi and have high resolution devices scale them. Doesn’t look as crisp you may say, but it didn’t stop people using the internet with them up until this point so I don’t see that as a negative, just as I don’t see static images as a con compared to interactive 3D models (though one could make the argument, of course).

    Retina displays still don’t fix 12MB product photos that still need to be zoomed in and scrolled around, so what is the effort for? I have to ask. And the answer for me, is for stock images that have no extra quality to offer in higher resolution over current resolution, or logos which are generally better off as vector anyway.

    • 15

      Bandwidth use has been on a continuous rise ever since the beginning of the internet. Sites just get richer and richer, which is a good thing.

      And the argument that higher and higher resolutions will come out doesn’t negate the need for a solution. If we find a solution that works well for 1x and 2x displays now and the industry moves on to 3x displays then at least we will already have a solution in place.

      There may not be a need for higher resolution images on the sites that you maintain, but that doesn’t mean that other sites don’t. Just say that flickr updates their site to use higher res photos that will take advantage of the new displays but photobucket doesn’t. Which do you think will more likely to take off when retina like displays become mainstream?

      • 16

        Sites are getting richer and richer, but no mere 2x or 4x display resolution is going to accomodate the current pace of default camera resolution … photos will still need to be resized below what such displays will be able to accomodate for the foreseeable future. And as this post is about the foreseeable future of large resolution displays and how to deliver images in this foreseeable future, it doesn’t change the fact that the reason people can/do still upload smaller resolution images is because they can be viewed by all devices (old, present and future) and hosting costs and uploading speeds stunt otherwise.

        I agree that hosting services such as photobucket could accomodate higher resolution images for retina displays, but they will still be far-below the typical resolution of original photos (thus still requiring multiple images or downloading very large images for small-resolution resizing) and not fix the problem between display resolution and source images that we already have … we could of course reduce the bluriness of 72dpi images on high resolution devices, but that is only because bandwidth.

        As technology has shown us in the last 10 years, advancements in bandwidth alone has been responsible the possibility of web apps as we know it … in year or two, it is highly likely that bandwidth will reduce the concern of scaling images and we can do away with creating multiple size images in large. This would truely be the better solution in my opinion, as these other alternatives are a bit like the hacks of several years ago which we are now busy re-doing with CSS3 and HTML5, so doing media query tricks and javascript tricks to handle multiple images is just repeating these hasty solutions – we only had to wait a couple of years for broadband to transform the HTML4 web landscape, imagine what we could do when broadband explodes at the rate it is presently progressing.

        As for forecasting whether higher resolution image hosting services/apps will become more mainstream, I suspect the higher resolution too. However when that happens, people will clearly still not want to maintain multiple sizes of each image as they don’t now (perhaps less so), so the only other option is to do it on the fly with realtime scaling, but browsers can largely handle that already … it is just a case of bandwidth; a solution that is not technologically controlled by web dev solutions like css or javascript, but the broadband providers. Just as it has been pre-HTML5 or XHTML.

        • 17

          Good points. I do think that, when looking at server resources, I’d prefer to make multiple sizes upon image upload, than resize on the fly. Then, it’s done once, and stored – save the CPU & RAM for serving pages & processing data.

          That also means less crunching on the client side, which I would think makes for faster pages. Mobile CPUs can choke on heavy JS solutions.

  5. 18

    If I use something like “letter-spacing: 0.5px”, will it be 1 retina pixel on webkit, or will it have no effect as usual?

  6. 19

    Great rundown of all the ways to present graphics; especially useful is the fact that you look at both pros and cons!

    I do think the opening statement about our graphics being “fuzzy and outdated” is a bit misleading, though. The graphics themselves aren’t fuzzy or outdated, they’re just being made fuzzy with an up-scaling algorithm, and there’s no way to up-scale that way without some ugly side-effects.

  7. 20

    Matt Berridge

    August 20, 2012 7:41 am

    A great roundup technically but the title annoyed me. Retina is just marketing from Apple, let’s not forget that and miss the bigger picture (pardon the pun!)

    I see the whole 1.5 / 2x min-device-pixel-ratio styles as a pretty crude fix. There are a few obvious short-falls – maintainability is one, data is another and forward compatibility is another. 2x pixel density will later become 3x…constraining things to a number of pixels (be that a density or a size of image you’re serving) is always going to be limiting. To that end I see SVG and icon fonts as key for the time being.

    I’d hate to think we are going to lose personality from websites, but perhaps we have to be more considerate at the design stage and strip our designs back until technology allows us to be more creative again? As has been covered above, with current solutions there’s always going to be at least one trade-off between graphic clarity / load time / browser compatibility / creativity.

    Predictably, I suppose “it depends” on the main objectives of the site. I guess that’s how the whole mobile/content first movement was born.

    • 21

      I think there has to be a server side solution to image resizing. coding it in the front end is not a very thought through idea. The servers need to be upgraded to provide the resizing solution for images.

      • 22

        Brett Jankord

        August 20, 2012 11:33 am

        You can resize images server-side, yet you cant get device-pixel-ratios from whats available to server-side code on initial page load. Solutions that serve responsive images from the cloud like have a JavaScript file to determine the device pixel ratio as well as some other device attributes before serving the image. User Agents alone are not enough to determine if a device has a retina/retina like display, and unfornately UAs are all we really have to work with on the server side when trying to figure out what image to load on initial page load.

        • 23

          Heiko Behrens

          August 23, 2012 4:32 am

          There’s a blog post by Shaun Inman discussing a server-side approach. First, some client-side JS stores the pixel ratio into a cookie. The server than takes this to decide which content to deliver for each subsequent image request.
          But: Most solutions ignore the fact that the pixel ration can change over time (e.g. by moving a window onto another screen). I combined the aforementioned conditional delivery with some JS to reload images (sort of cache buster) but cache URLs whenever the ration changes. Have a look at RetinaTest-OSX that demonstrates this with an embedded web view. It could easily be adapted for ordinary web pages as well.

      • 24

        John Surdakowski

        August 21, 2012 5:44 am

        Totally agree with Ben. But it would also be nice to have a new image format, that would serve the appropriate version of itself, as needed.

    • 25

      2x pixel density will later become 3x

      Highly unlikely. Once you’ve hit ~220PPI for desktop or ~260PPI for a mobile device, there’s simply no benefit in increasing pixel density. As a point of reference, dot density in printing has been stable for a long time.

      To that end I see SVG and icon fonts as key for the time being.

      SVG is brilliant for things that are possible with SVG. But remember that SVG is drawn at runtime, so performance for complex icons and images is an issue. Also, there’s a lot of things that simply aren’t possible with SVG. You can’t easily (or sanely) represent a photo as a vector. And if you embed a bitmap image within an SVG, it’s still a bitmap. So you may as well be using bitmaps in some cases anyway.

      And icon fonts don’t have the pixel accuracy that SVG and bitmap formats like PNG, GIF and JPEG provide.

      It’s important to know the pros and cons of all the methods available and choose the right tech for the job.

      • 26

        Matt Berridge

        August 21, 2012 12:31 am


        That’s interesting about pixel density, if you think it will remain at 2x then I guess that potentially sures existing CSS solutions up a bit.

        Of course SVG has its limitations too. Hence my point about designs losing personality and becoming too “2D” – because they can only be used for simpler graphics.

      • 27

        I’m having having trouble finding the link but I recently read a great article explaining that Retina really isn’t “retina”. 20/20 vision is not perfect vision. It means passing the familiar letter reading test, a test designed to fit a particular average. Only at 900PPI and higher people with the best vision will no longer see any difference with higher or lower PPIs.

    • 29

      You should try to get ok with people using the term “retina” to refer to high-density displays.

      You know, sorta like how people say “podcast” when they mean “digital media consisting of an episodic series of audio, video, PDF, or ePub files subscribed to and downloaded through web syndication or streamed online to a computer or mobile device”.

  8. 30

    Please note the font example is not accessible. This is especially true if using the letter a to represent an action within a link. If this is the approach you take, add aria-label to the container.
    <span class=”icon” aria-label=”Save for later”>a</span>

    • 31

      aria-label is not vocalized by assistive technologies in a span like in the example you give.
      I tested it with the latest NVDA version.
      It would have no effect.

      Anyway WAI-ARIA provides really cool accessibility solutions. the way assistive technologies choose to use it is another thing.

      But i really appreciate you focus on accessibility issues.


  9. 32

    Awesome article!

  10. 33

    Super great article, great work.

  11. 34

    Mike McGrail (@mike_mcgrail)

    August 20, 2012 8:16 am

    I now have Retina screens across all of my devices and things are slowly coming up to scratch. Got the new MBP 3 weeks ago and even then, Chrome wasn’t optimised, it is now and it looks amazing.

    I have no idea what 99% of the technical stuff in this post means, but I can tell it is a really valuable post, nice one.

  12. 35

    That’s a very nice and elucidative article. But I disagree when you say “Because a bitmap pixel can’t be further divided, it gets multiplied by four on Retina displays to preserve the same physical size of the image, losing detail along the way.”

    Actually, the bitmap isn’t losing any detail, it’s being represented exactly as it is. It’s just not fully using screen capacity.

    • 36

      Think of it this way, if you take a regular image that is say 10px by 10px and scale it up to 20px by 20px, it will appear fuzzy and blurry, the same thing happens if you try to render a 10px by 10px image on a retina screen, the image will appear worse than it would if rendered on a non-retina screen.

      • 37

        That’s not true.

        If you are doubling pixel density and scale a 10×10 image to 20×20 on the 2x screen, it will look the same given identical screen sizes. With the double density screen you are packing 4 pixels into the space of a single pixel on the other screen.

        • 38

          Have you ever loaded up an app in a retina iPhone or iPad and found the graphics to be horribly fuzzy?

          That’s the result of standard resolution (“non-retina”) images on a retina display. Regardless of whether the image actually loses detail, the practical result is, in fact, fuzzy images (makes sense, really — the 1-pixel wide gray “shadows” that give lines a soft feel have suddenly become 2 pixels wide, making it look fuzzy instead of just soft). We learned this the hard way where I used to work, before we knew that would happen.

        • 39

          My question, exactly, Lee. Below Shauna says that the gray shadow becomes blurry because the gray takes up 2px instead of 1, but those two retina device pixels take up the space of 1 standard device px. So shouldn’t the upscaled image look the same?

      • 40

        @Luis is actually correct. Only when you downscale you lose details, since you have more pixels than you have room to display them in. When you upscale you do not lose details at all, you’re making details larger, not losing them.

  13. 41

    Jose Tavares (@MiamiDesign)

    August 20, 2012 9:44 am

    This is a wonderful article Reda!

  14. 42

    The one thing I never understood is why do images appear blurry on the retina screen? Why not just upscale 2x pixels instead of interpolating the image?

    • 43

      Someone made the choice for you. Also, they have decided not to give you that option. I prefer it myself.

      However I don’t have any of these issues with my websites. I use CSS percentages, and rely on bitmap graphics if the vector Flash media format is not loading (or no plugin). But Adobe has given that up and now the only option is SVG, failing back to JPGs resized to fit the correct design spec percentage.

      If anyone gives me a design spec that has CSS in Pixels, that’s a big red flag!

  15. 44

    Creating high resolution versions of every image on a site is not good, even if there was good syntax for it.
    1. The extra bloat of retina images significantly increases the time it takes to load every page.
    2. The images consume more memory, which can lead to poor performance, and even increase the risk of browser crashes on low memory devices.
    3. Resizing images to fit in non-retina displays causes image interpolation, which is a huge burden in most browsers.
    4. Any complicated site has a content management system. Having clients upload retina images is time consuming and won’t be easy for less tech savvy users.
    5. It’s not really worth sacrificing the user experience of most just to satisfy a minority of users with retina display on fast connections.

    So what should you do when your client complains that their website looks blurry, unprofessional, and just plain ugly on retina displays?

    From my observations, there are only two things that really look offensive on websites when viewed on retina displays:
    – graphic text
    – logos and branding

    If you care about SEO, you stopped using graphic text long ago, and are happily using CSS fonts or cufon. So that’s no problem.

    Therefore, logos are really the only significant issue for retina. A logo should always look good and inspire confidence in the brand or website. It’s also the first thing a user is likely to notice, and it’s likely repeated on every page. This should definitely get the retina treatment.

    Because most logos are made in Illustrator, SVG is a natural fit, because you can simply export an SVG from Illustrator. You also need a bitmap, for browsers that don’t support SVG. You will also never have to update it again, even when 4x, 8x, and 16x retina displays are released.

    Here’s some code I wrote, showing how to seamlessly replace a bitmap with a vector graphic, using progressive enhancement:

    • 45

      Matthew Dance

      August 21, 2012 5:57 am

      Does that mean Apple doesn’t care about SEO? Serious question. They use graphic text all over the place. You wouldn’t know unless you actually look. It’s quit interesting.

    • 46

      Also @Matthew Dance:

      Your point about SEO is not true. Browsers, screen readers and search engine crawlers are perfectly capable of reading the alt and title tags of a graphic text.

      Even with css3, there is still stuff you can’t do to text to make it look exactly like you want it to (like per-character gradients with reflective gloss).

      Also, if cufon (or the dead sIFR, for that matter) is in canvas/flash mode it’s much less readable to screen readers then an image with a decent alt tag. You can also put an image with alt tag in a header (h1,h2,…) tag and everything will be peachy!

  16. 47

    Good round-up, one bone of contention stuck out, however. It’s my understanding that you want to reverse the order of your css selectors to something like this:

    This results in the unprefixed (and eventually implemented correctly) rule from taking precedent over vendor specific implementations.

    • 48

      Good point. Also I wonder why the first letter of all -webkit-properties is uppercased. It doesn’t break anything but looks strange a bit.

  17. 49

    Or, as I’ve summarized for my manager, “There is, currently, no good solution.” (Especially for responsive/adaptive/single source sites.)

  18. 50

    “Apple has brought double-density screens to all of the product categories in its current lineup”

    Huh? I don’t recall Apple announcing a Retina-version in either of it’s iMac or Mac Pro/Thunderbolt Display categories. And given the pixel-pushing limitations of graphics card capabilities for the foreseeable future I doubt I’d want a Retina display in either a 27″ iMac or Thunderbolt display anytime in the next 4-5 years (and I definitely don’t want a Retina MBP considering its puny mobile graphics card).

    Don’t get me wrong, the article is exceptionally well-written but by the time I will actually need any of this information I will have forgotten where I read it.

  19. 51

    The jQuery resizing example, in pure JS:

    window.onload = function () {
        var images = document.getElementsByTagName('img'), i;
        for (i = 0; i < images.length; i += 1) {
            images[i].width = images[i].width / 2;
  20. 52

    First of all, great article, thanks- Thought about that many times; couldn’t get it straight; too lazy to google the problem. So am I right now:

    I still wonder how iOS knows when to stretch an image and when not.

    What does it with an img tagg WITHOUT width or height attr or css declaration that limits the css pixels?

    Let’s say it should be fitting in 200×300 CSS pixels- but the actual image has as retina needs 400×600 pixels. The way I got it in my mind iOS now displays an image with 400×600 CSS pixels and by this stretches the image to 800×1200 device pixels.

    Clear the dust please!
    Thanks :)

  21. 53

    Flash scales perfectly – especially if everything you do in it is procedural. It’s also an order of magnitude faster to render than SVG.

    I guess those iphone thingys don’t support it. That’s a shame. OTOH, here in the article it says that javascript polling for retina displays might not be supported by all browsers — specifically:

    “Does not work on some popular browsers (such as IE and Firefox).”

    Oops, there goes like, 80% of the web audience.

    I’m a mac user, but I don’t make the mistake of only designing for other apple fans, and neither should you. Use the technology appropriate to the job. If you need full-scalable sharp imagery across displays, you’re either going to have to use Flash or invest a huge amount of time rolling your own dual- or triple-resolution fallbacks the way Google does. Consider whether your client wants to pay for that, and if they do, go for it. If not, alert them to the search- and unhipness- issues surrounding Flash at the moment, and let them decide whether they want a super hip website that only works in Chrome and iOS, or a really nice one that works on everything except an iphone.

  22. 55

    The issue is that because retina is so tiny, they are doubling the size of everything to appear as 1920×1080; this in turn makes every image you view pixelated, unless vector. Photography images are not as sharp, and many items that wouldn’t be vector won’t be as sharp, the way to fix this is make the images twice the size and resize depending on retina or non-retina…I feel as if we will be designing two websites per website now to make up for retina and non-retina…maybe I’m wrong, but I’ve been designing on retina recently(mainly items that can’t be vector) and it’s been pissing me off to not be able to see it sharp, or 1px lines in photoshop are blurry etc…:/

  23. 56

    What’s the best way to handle retina resolutions when designing in Photoshop? Usually I’ll have our designers do their designs in a Photoshop doc that is about 1200px wide to handle a site for 1024 res users. Now that retina is double the px resolution should I have the designers use a 2400px wide photoshop doc and work at 50% zoom? What’s the best way to handle this?

  24. 57

    Oh when is this new technology crap going to be over already?!

    In all seriousness though, the whole retina & high DPI movement is going to help us do what we do best: design awesome looking interfaces.

    The higher the DPI, the more pixels we have to work with when creating icons.

    Rounded corners will be sharper than ever.

    Heck, at some point, dithering might even become relevant again!

    All it does, is give us more tools to do our job. Yes, there’s an extra challenge in cross-platform consistency, but that’s what we designers need every now and then: to get down from our cloud, stop being floaty for a bit, and get our hands dirty with our nasty programming developer friends.

    Gotta love the web.


  25. 58

    For years, due to my print background, I have always designed my sites in AI. I find that illustrator has a better methodology for organising “objects” vs layer after layer of details. With this Retina trend, it seems that the SVG might re-enforce this. Does anyone have a methodology or best practices with this?

  26. 59

    There is a server side solution available, which automatically create and deliver the image in the right resolution. It also needs no markup changes:

  27. 60

    Oh Please Stop with the “retina web” nonsense! Web images are fine as is. Native apps are completely different and only work on Apple devices, and have the luxury of downloading all at once on the initial install. We build web sites for everyone, not just Apple retina displays. There is no indication that everyone’s monitors will be retina any time soon. And here’s the other really important thing – web images such as JPEG photos look completely acceptable on retina displays. If they were broken, or looked really blurry or otherwise hideous, then yes you’d have a point. Please stop this stupid push to get web developers and producers to start catering for Apple retina displays, which represent a TINY portion of visitors and will for a LONG time, even among Apple Mac owners. Seriously guys.. you obviously don’t build websites, or are involved in defining a sensible budget for website builds and ongoing maintenance, because if you did, you’d know that investing in secondary “retina” images for your content is not a good strategy and the cost and hassle far outweighs any perceived benefit.

    • 61

      I agree with your words. We build web sites for everyone, not just Apple retina displays.

    • 62

      I have to agree on most of your post but the whole “Apple only”- thing is just nonsense. Most high-end smartphones are delivered these days with high resolution displays. the Samsung I9300 Galaxy S III for example is fitted with a 306ppi density screen…

    • 63

      I agree completely. May be when my kids at college all displays will be high resolution displays. At this point it’s to early to talk about Retina and optimizing, creating hacks, create crazy scripts just to make sure images looks good on iPad3, iPhone 4 and MacBook Retina. I won’t even bother with this nonsense until this technology is more relevant and well adopted.

      • 64

        iPod Touch, iPhone, iPad, MacBook Pro, Samsung Galaxy SIII, Samsung Galaxy Note or even a Nintendo 3DS (less relevant, but still has 236.61PPI!)…

        High resolution displays is not something going on solely at the apple front. It’s a big thing like megahertz’s were once a big thing and like “the wheel” was once a big thing. Ignorance is not going to change that!

      • 65

        HELLO 1995!!!! Remember ‘lowsrc’ ????

        For those exclusive to retina-targeted sites, this info is immensely useful.
        To the rest of the Web, it is just something more to keep in the back of our minds should it ever come up at geek trivia night.

  28. 66

    nice article …at the right time…keep it up Reda..

  29. 67

    I Don’t think so is this a grate article unless we get freedom from pixels devices. But we do have an option to render from svg format.

  30. 68


    August 21, 2012 12:43 am

    There’s a handy WordPress plugin that can help you serve high res images to your retina users while not forcing others to load those big files:

  31. 69

    Great article Reda.

    If it would be OK I’d like to make you all aware of a service we have just launched, which completely takes the headache out of all retina / responsive image delivery. delivers responsive images on-demand, direct from the cloud. It delivers images at the right pixel size for the device viewing your application. The right quality of image for your current connection speed, and full Retina support for the latest screens with enhanced PPI resolution displays. You even keep total control of your images so you can add whatever sizes, crops, optimizations & effects you want.

    We are in a public beta which is completely free to use.

    • 70

      I’ve used – looks like this has more features (cropping would be nice). Will def. check it out.

  32. 71

    To be honest, i didn´t read the full article, only passed trough the titles. But i got the point. What i was really interested, was on the comments sections.

    It´s true that recent mobile devices also uses this high dense pixel resolutions, however (and as the intro of this article refers) i think all this interest is mostly caused by the Macbook Pro Retina Display. It´s a little sad to see people willing to give all this hardwork to satisfy (mostly) the needs of one piece of hardware.

    This article is a good example of what i think it´s the different visions between Web ‘Developpers’ and Web ‘Designers’. In this same site, a few time ago, there a couple of articles saying that we should stop supporting older browsers. Now how come we should be interested in supporting such a recent and barely used technology, and throw way our attention from browsers that lot of people still use. I don´t mean start again with that browser discussions, but what it´s the criteria?…. if it´s a technology that gets things pretty it´s ok, if don´t lets not worry about it?

    I think developpers should have consistent arguments. If we support some technology for the sake of the user experience, then that argument should serve to all other cases.

  33. 72

    This article was fine… however, I do not see any monetary gain in developing for a very, very small percentage of people with Retina MacBook Pros. Taking the extra time to do this would be a poor business decision and a waste of time.

  34. 73

    Responding to the New High-Resolution Web [presentation]:

  35. 74

    David Knikols

    August 21, 2012 3:58 pm

    This is what will finally kill Photoshop as the web choice leader and reign in Illustrator, who has struggle with finding its own, but will finally become the chosen forgotten one..

  36. 75

    David Knikols

    August 21, 2012 4:11 pm

    The audience is not there and when it comes I believe design software development will provide the answer…when the need is big enough the demand materializes solutions. So no sleep lost on this one. As a designer this one is a nightmare for the providers of this technology not us

  37. 76

    How might this fit into the mix?

    I’ve been using it with great success thus far.

  38. 77

    Nice article and good coverage of techniques. One thing you did miss is that going forward the standard will be @media (min-resolution: 2dppx) {} which will match devices with 2 dots per px (dppx) the -webkit-device-pixel-ratio will not be adopted. This has already landed in Firefox.

  39. 78

    Vigneshwar Raj

    August 21, 2012 7:13 pm

    ‘Towards a Retina Web’ – Great Roundup!
    Designing and developing for all the displays is a tedious process including retina. Designing web alone for retina is not a encouraging idea, we need to consider other displays too.
    Apple seems to be taking a lot of time to optimise their own website for retina web, they itself having a quite tough time in making it. Understanding the difficulty, hope they will bring the finer solutions. There are lot of ideas in the various blogs for retina display design, but how much of them are perfect?

  40. 79

    last week had to move my ass to apple store and check how project looks on a new MP coz client’s complain.

    it has also some option to zoom in/out whole display which makes issue even more complicated.

  41. 80

    Is Apple has patent for Ratina already?

  42. 81

    When thinking of scaling. I hope that we will see more web designers start thinking of what units they are using. Example, many sites still uses font-sizes in px instead of procent/em.

  43. 82

    So what’s the effect of using a larger image and then downsizing it with CSS via the width or max-width properties? Won’t that translate to a higher pixel density on retina displays?

    Edit: I’m referring to images placed with the img tag, not as a div background.

  44. 83

    Nice article, good info.

    allthough i think many people are getting stressed out about this when they really shouldn’t.

    At the moment there’s no way i’m going to design a normal webpage at double resolution for the apple retina display, let them make it work on their screens.

    If clients want to have ‘retina’ ( what a stupid term ) supported they surely have to pay more, cause it just realy takes more time.
    And i think that’s realy a downside to all this retina stuff no one talks about ( not that i’ve seen anyway ) : more different screens > more work > higher prices.

    I hope these varius screen densities won’t become some sort of “Stop supporting IE6” issues. Hell i already see those stupid articles showing up… but let’s hope not!

    And i also hope that after this retina thing they won’t go any too further, you can’t see the pixels with your eyes anyway so why bother for a 4x retina density screen or something like that.

  45. 84

    Just to mention about one thing that please don`t say the density is doubled. Because is quadrupled and the whole data in average between iPad2 and iPad3 are 4x bigger. Also the fact about the data even for the simple games asking for huge amount of graphic assets is ridiculous. And + HTML5 is simply suicide. Hallelujah Steve … and your marketing plan to destroy vector graphic and flash and go backward 6years … even in the effectiveness of the work production. And graphic flexibility… So towards to retina display and backwards in web platform based on the JS :) and complicate everything and go to ice age with vector graphic and simplified editing worse then giving a birth. Instead of using interpreted mathematics doing excellent graphic like a flash stretching as you want and animate as you want forced to use weird stupid bitmap sprite sheets like for commodore C64. in retina time veeeery clever ! Congratulation ! :) Just my thought about my last design project for iPad3… vs iPad2… vs iPhone.. vs any other smartphone device + Android platform. For one game… – result ? :D Everybody have to download shit load of everything… To see for instance rolling dice :) on the board game like Monopoly… I think now is towards to high res apple issue monopoly now… And for designers… just tears and pain and nerves and more suicides thanks to … R.I.P …

  46. 85

    Good post! As a designer I started doing some testing with Retina images and come to a stunning conclusion. It IS possible to compress the hell out of Retina images and still get a sharper image on Retina screens. The Retina images are even smaller than normal resolution images, Sounds impossible, but true! You can read a blogpost about this phenomenon with lots of test images here:

    Hopefully a small contribution to the discussion!


  47. 86

    Does -webkit-image-set work in webkit mobile browsers or is this just implemented in the latest versions of Safari and Chrome for the desktop?

  48. 87

    Peter Garrett

    August 27, 2012 2:13 pm

    I think the sheer number of comments on this post goes to show what an important topic it is. I found myself out at the Apple store this weekend, checking out the displays on the new ipad to see what effect some of my websites had.

    I’ve got to admit, that although the imagery was noticeable different, it was only so to the keen eye of a designer. My partner hadn’t even spotted it, and it took quite of lot of examples before she did.

    Still, great article and great comments!

  49. 88

    Scott Jehl’s Picturefill looks like best method for what I need – “While numerous other solutions exist, picturefill has the added benefit of performance for the user in only getting served one image.”

  50. 89

    Yet another pain in the a**!
    However, great article. And just for the record, when l decide to tackle the problem I’m going to double the size of my images and go for the:
    transform: scale (2.0,2.0); method using css.

    It’s supported by all the major browsers, but l think it might bloat my website download time by a factor of 2.0! Oh yeah!

    1 x 2 = 2

    2 x 0.5 = 1

    Have a nice day!!

  51. 90

    We are still talking terrible load times for mobile devices. Just because the new iPhones have the retina displays, still does not mean it has the capabilities to render larger DPI images reliably through a 3G or 4G networks. Maybe, maybe wireless, and that is only dependent on the wireless mps. Just because Apple decided to up the pixel resolution on their displays kind of screwed us and themselves. Us mainly because web developers and app developers need to retool just about everything to meet Apple’s standards. Granted the images would look great, but still does not constitute web designers/developers needing to make 2-4 copies of the same images just to accommodate the different resolutions. Apple breaks out the high density screens and then offers no tools to help us with our design needs. We are left with the bag and the shaft with them saying “Here, figure it out.” Adding images that will fit the retina displays on mobile devices (mainly iPhones) will cause slower load times. The internet can only serve up as many bytes as the pipeline allows. If we need to double our DPI on our images to anything to look good means the longer wait times on our sites and unhappy or frustrated customers who view our sites. Leaves us writing a bunch more code and hacks to try to accommodate the new displays. Reminds me of the way we all have to deal with IE hacks we have to use to accommodate our customers. This is only making it worse now.
    Kind of a pain more than an advancement.

  52. 91

    I’m about to pick up a retina macbook and I’m scared to death to look at any sites I’ve made now…

  53. 92

    According to Thomas Fuchs, for content images, you can merely double the resolution of your original image and lower the quality to keep the file size down; after defining the original widths and heights that image was intended to be, you have a retina-ready image without any additional markup.

    Art Direction images and images of that nature would benefit from the techniques above.

    Just thought I’d point that out….

  54. 93

    I am getting confused on the numbers. If the surface density is double, wouldn’t that make it 2 pixels for every 1 pixel on a traditional monitor? Or is the measurement calculated in both vertical and horizontal making it 4 pixels for every 1 pixel on a traditional monitor? If it is 4 pixels, then why are the example image sizes only doubled? Shouldn’t a 200 × 300 size image be 800 x 1200 (x4) to take full advantage of a double density display? I guess I am getting confused on device pixels because from an image size perspective (number of pixels in an image) how does a 400 × 600 size image in lieu of a 200 × 300 size image result in four times more pixels?

    Lastly, graphics for display monitors have traditionally been at 72 DPI. Why not quadruple the DPI? Would that not cater to higher density displays in the same way?

    • 94

      2 times linear (in both directions) is 4 times square. So 200×300 px is 400×600 retina px (60 000 px² is 240 000 retina px²) [of course, I use px² notation just to distinguish 1D pixels from 2D pixels]

  55. 95

    There’s a really simple JS plugin for retinising your inline images called retinise.js

    It uses custom attributes to save bandwidth by only serving up the image you need.

    If you are worried about JS being disabled then you can just use a noscript tag to fall back on.

    Like I say it’s not the most complex solution out there but it was built to be really simple and for the size of the plugin it does as good as if not a better job than the plugins already out there.

    You can get it here:

  56. 96

    I have set up a page to test the media feature of any device / browser right there:

    Hope this helps. I also have a page which recaps the media features of most devices as measured by this test.

  57. 97

    Chris Ferdinandi

    October 27, 2012 9:33 pm

    A few quick notes on icon fonts:

    1. I’ve been using them extensively for the last six months. Simply put, they’re awesome.
    2. Twitter Bootstap actually uses sprites, not an icon font, although the Font Awesome icon font is designed to integrate with Bootstrap.
    3. I can’t say enough good things about the IcoMoon font set an app. It lets you create your own custom font with only the icons you need.

  58. 98

    For years I’ve gone to great lengths to have my pure CSS/HTML page element sizes expressed in percentages, flowing with the window width. Those with bigger screens get what they payed for, those with smaller screens still can enjoy the pages.

    The only flaw in most browsers I found (Safari 4 being an exception), and wasn’t a problem until retina displays emerged, is that in clickable image maps the ‘length’ cannot be expressed in percentage, but has to be stated in px, em or other fixed units. I’m afraid I’ll have to implement your thoughts on retinas just to get my image maps working again (and I’m open to suggestions to make all my image maps liquid.)

  59. 99

    I find it curious how many of the comments seem to discuss this as if it was merely an issue for users of Apple products (or even go so far as to be unhappy with Apple for introducing these displays to the mass market). My first encounter with high-density displays was, I believe, with some late-model palm devices; I remember how, at the time, their text was incredibly crisp and easy-to-read. I had a similar reaction to the first “retina” iPhones, and I now really appreciate the print-like text on my MBPro; the benefit is obvious, and while such screens demand a premium today, it seems likely that they will become standard eventually. Even now, this feature is not restricted to Apple; according to Android developer info, about 50% of the active Android devices use high-density displays (though as noted their definition may be different than Apple’s). As Pierre writes, it’s early days yet; it’s not urgent to implement an immediate solution, but as both he and Reda write, it’s time to start thinking about how such solutions will be reached.

  60. 100

    One Question! Who has web dev/design clients jumping to pay for this? Not me.

    Unfortunately, my small B2B clients aren’t interested in Retina yet (or social media or responsive design or perfect browser compatibility). In this economy, I have to prove new technologies add to their PROFITS.

    Meanwhile, I’ll keep a close eye on WWW3Schools statistics – they aren’t even measuring Retina yet. Moreover, Safari and Apple OS are barely in double digits.

    Still, it’s inevitable, just like high-def television.

    Finally, don’t know the demographics of this forum, but as a bifocal wearer … font size and clarity is more than just a “nice to have.”

    Thanks for the great post and comments. Smashing is the best!

  61. 101

    I think this whole thing is very important and NOT an Apple-specific thing. It is also not only usefull for Retina/HiRes-Displays, but for everyone.

    There are more and more Multitouch-Devices (Smartphones and Tablets) on the market and on that devices it is absolutely normal to zoom into webpages. Even if they have low-res displays.

    So I personally don’t like the solution Apple is using on it’s own website. If I use my MBP 13″ (non-retina) or any tablet/phone, etc. or other computer and want to see their pictures better, I zoom in and get blurry, ugly pictures. When I zoom in on the Retina iPad of a friend, the pictures look fine zoomed in and you can clearly see details of their products.

    So in my opinion every Device should get the higher-resolution images, not only those with hi-res displays. If they are well compressed the file size is mostly not much higher.

    I hate it, that on some websites you only get the crisp images with Retina-Devices. I want to see the sharp images also on the non-retina devices. Think of any iPad from version 1 to the iPad mini or any Android tablet. You zoom in and get blurry pictures, no fun. On the iPhone 4+ you get the fine pictures, even if it is not so important there.

    I think best is SVG, when possible and if not, you should try to use pictures with double the pixel-size in width and height, so everyone can benefit from it, not only Hi-res devices, which are many today, not just 2 as someone said.
    Some examples: Google Nexus 7 Tab, Google Nexus 10 Tab, some other Tabs, a LOT of different Smartphones and of course also the Apple-Stuff, like iPhone, iPad and MBP-Retina.

    But as said, it is the absolute standard that you zoom into webpages on EVERY Tablet/Smartphone, not only the hires ones. So it is better to provide hires images to EVERYONE.
    Of course you can offer a lo-res version for low bandwidth as an option. (if it really makes a big difference in file size)

    Also it is common on other devices (PCs, Laptops) to zoom into websites. I think every browser has this function and it gets more and more common, not only on tablets.

  62. 102

    This is a complete joke… It’s hard enough having to create websites for mobile and desktop versions and then responsive for different monitor widths and now you want hi res display sites think of all the extra permutations. Then you add in different languages (images)… I mean really enough is enough!

    The web is getting insane you have to do more and more each year for the same $ amount or often less then what you got 10 years ago.

    There comes a breaking point… And often the people wanting arnt the web designers or builders or really know what’s involved or how much time goes in it.

    This is just a ego fad that project managers and clients will be asking in the hope it makes them seem smart in asking for it… Put your foot down web developers and say NO!

    It’s bad enough with browser testing and working with old versions.

    The web has turned in to an ugly beast of mass hacks and work arounds – world wide web of duct tape.

    It’s starting to look like a horror movie freddie cruger

    P.s. server side pushing of images is the best method I do that already, just makes sure you use a caching method to prevent to much server loading.

  63. 103

    Krispijn Joseph

    December 28, 2012 4:28 am

    A great post thx!

  64. 104


    Great post, thanks !
    However I have troubles using the CSS Media Query + background-images method on Windows Phone 7&8, see :

    Since I am targeting all mobile platforms, I cannot use this solution.
    Maybe you should add transparent images incompatibility on WP7/8 to the “Cons” of this method.


  65. 105

    “an image rendered with four times fewer pixels than its full bitmap size”

    should be:

    “an image rendered at 1/4 of its full bitmap size”

  66. 106

    Thanks for sharing this useful post .

  67. 107

    Thanks, good post! Although I have no idea how i could integrate ‘retina’ image processing into a CMS system! ack.

    Anyway, I understand the points about ‘we’re not just designing for Apple users’ etc.. But I was thinking that in terms of ‘future-proofing’ (okay to a point) surely this can’t be ignored.

    And as already said, not just apple, look at the new chromebook, the nexus 4, samsung galaxy 3/4 etc… they’re all high res. Plus 4k televisions are coming. It’s all going ‘hi-res’ just a question of when.

  68. 108

    Mentioned java-script solutions will load big image and small image for regular screen. You can simply check it with browser profiler.
    And what the point of doing it? :)))

    We found client-side solution that works without twice image loading, though it is not ideal

    BTW, why users of this site should scroll thousand comments before answering to the article (great UX)?


↑ Back to top