Menu Search
Jump to the content X X
Smashing Conf New York

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. upcoming SmashingConf Barcelona, dedicated to smart front-end techniques and design patterns.

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.

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 Pixels1

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 Pixels2

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 Displays3
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:

device-pixel-ratio,
     -o-device-pixel-ratio,
   -moz-device-pixel-ratio,
-webkit-device-pixel-ratio {
…
}

Or you can use their future-proof siblings:

device-pixel-ratio,
     -o-min-device-pixel-ratio,
   min--moz-device-pixel-ratio,
-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 Pixels4

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 Displays5
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 works6
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 works7
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;
  content:'';
  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 Density8

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:

$(document).ready(function(){
  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.js9 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 compatible10.

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 Graphics11

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 support12 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 Inkscape13.

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 Modernizr14:

.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 headaches15 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:

$(document).ready(function(){
  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 Fonts16

Popularized by Twitter’s Bootstrap17, 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 shortage18 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 Fontello19, Font Builder20 or even Inkscape21.

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 Xcode22) or with Icon Slate23, 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, introduced24 last spring. This proposal allows for25 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 Picturefill26, 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 -->
  <noscript>
    <img src="example.png" >
  </noscript>
</div>

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 proposal27 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 shifts28 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.

(al)

Footnotes Link

  1. 1 https://www.smashingmagazine.com/wp-content/uploads/2012/07/device-pixels.png
  2. 2 https://www.smashingmagazine.com/wp-content/uploads/2012/07/css-pixels.png
  3. 3 https://www.smashingmagazine.com/wp-content/uploads/2012/07/css-device-pixels.png
  4. 4 https://www.smashingmagazine.com/wp-content/uploads/2012/07/bitmap-pixels.png
  5. 5 https://www.smashingmagazine.com/wp-content/uploads/2012/07/css-device-bitmap-pixels.png
  6. 6 https://www.smashingmagazine.com/wp-content/uploads/2012/07/downsampling.png
  7. 7 https://www.smashingmagazine.com/wp-content/uploads/2012/07/html-sizing.png
  8. 8 https://www.smashingmagazine.com/wp-content/uploads/2012/07/querying.png
  9. 9 http://retinajs.com
  10. 10 http://www.quirksmode.org/blog/archives/2012/06/devicepixelrati.html#link2
  11. 11 https://www.smashingmagazine.com/wp-content/uploads/2012/07/svg1.png
  12. 12 http://caniuse.com/#search=svg
  13. 13 http://inkscape.org/
  14. 14 http://modernizr.com/docs/#features-misc
  15. 15 http://dbushell.com/2012/03/11/svg-all-fun-and-games/
  16. 16 https://www.smashingmagazine.com/wp-content/uploads/2012/07/icon-fonts.png
  17. 17 http://twitter.github.com/bootstrap/
  18. 18 http://www.delicious.com/stacks/view/SC3hpq
  19. 19 http://fontello.com/
  20. 20 https://github.com/fontello/font-builder
  21. 21 http://www.Webdesignerdepot.com/2012/01/how-to-make-your-own-icon-Webfont/
  22. 22 https://developer.apple.com/downloads/
  23. 23 http://itunes.apple.com/us/app/icon-slate/id439697913?mt=12
  24. 24 http://trac.Webkit.org/changeset/111637
  25. 25 http://lists.w3.org/Archives/Public/www-style/2012Feb/1103.html
  26. 26 https://github.com/scottjehl/picturefill
  27. 27 http://www.w3.org/community/respimg/wiki/Picture_Element_Proposal
  28. 28 http://robots.thoughtbot.com/post/23288959017/designing-for-touch
SmashingConf New York

Hold on, Tiger! Thank you for reading the article. Did you know that we also publish printed books and run friendly conferences – crafted for pros like you? Like SmashingConf Barcelona, on October 25–26, with smart design patterns and front-end techniques.

↑ Back to top Tweet itShare on Facebook

Advertisement

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.

    4
  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?

    1
    • 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.

      7
    • 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.

      4
    • 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?

      0
    • 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?

      0
    • 9

      LessLessMoreMor

      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.

      2
    • 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.

      0
  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!

    0
    • 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.

      0
    • 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!

      3
  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.

    0
    • 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?

      0
      • 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.

        0
        • 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.

          0
  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?

    1
  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.

    0
  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.

    0
    • 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.

      0
      • 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 reSrc.it 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.

        0
        • 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.

          0
      • 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.

        0
    • 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.

      0
      • 26

        Matt Berridge

        August 21, 2012 12:31 am

        Marc,

        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.

        -1
      • 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.

        0
    • 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”.

      0
  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>

    0
    • 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.

      Regards.

      -1
  9. 32

    Awesome article!

    0
  10. 33

    Super great article, great work.

    0
  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.

    0
  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.

    0
    • 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.

      0
      • 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.

        0
        • 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.

          0
        • 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?

          0
      • 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.

        2
  13. 41

    Jose Tavares (@MiamiDesign)

    August 20, 2012 9:44 am

    This is a wonderful article Reda!

    0
  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?

    0
    • 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!

      0
  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:
    http://jsfiddle.net/95zF5/1/

    1
    • 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.

      0
    • 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!

      0
  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:
    -Webkit-device-pixel-ratio,
    -o-device-pixel-ratio,
    -moz-device-pixel-ratio,
    device-pixel-ratio

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

    0
    • 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.

      0
  17. 49

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

    0
  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.

    0
  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;
        }
    };
    
    0
  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 :)

    0

↑ Back to top