Question

I’ll try to sum this up as best as possible. I’m developing a web application which needs to be:

• Responsive, with emphasis in desktop and iPhone (retina display)
• Supportive of all modern browsers plus ie8 and ie9
• Server-efficient, meaning: as little JS and as many icons inside a sprite as possible

Targeting device width/height vs Targeting pixel ratio:

For the conditional CSS, I went for targeting pixel ratio instead of creating different layouts for specific platforms and devices or using the safari user agent. So I’m using @media (-webkit-min-device-pixel-ratio: 2) plus all my responsive styles.

Now I’m trying to decide how to deal with the images.

Two images for each background vs One image with background-resize

Because I want to keep the server request as fewer as possible, I’m using sprites (4 or 5 “stencils”) instead of separate pngs (the SVG discussion is another thing!). But Background-size is NOT supported by IE8, a big portion of my users, so it needs a JS fallback like jquery.backgroundSize.js.

So:

Is the combination of sprites, conditional background-size and a JS fallback for IE8 the best option, from a performance and good-practise point of view?

I didn’t find other questions with this specific (yet quite common nowadays) scenario. It’s not intended as a discussion question, I’m more interested in knowing if there is an actual agreement on how to deal with the situation: Retina display, sprites, IE and JS.

Answer 1

Conditional background-size would not be the preferred option. If you chose to use the property to use hi-res sprites for clients with “normal” pixel ratio, you’d end up with lower image quality than that of a pre-rendered image, additional computational overhead for the client to scale the graphic and transferring ~4 times larger sprites than needed. By relying on background-size you also end up artificially limiting your site’s compatibility with legacy browsers, while an IE8 JS fallback is also likely to introduce content flicker (whether or not acceptable in your scenario).

I’d go with pre-rendered versions per pixel ratio (so you effectively end up with twice the image files). You’d be able to provide the user with better quality graphics than background-size ever could. If you build sprites manually (as opposed to generating them and accompanying css with an automated tool), this would introduce maintenance overhead but the solution would be overall preferable.

1. Make a high-dpi version of your css file e.g. main-highdpi.css and conditionally include it with an appropriate media query not unlike <link rel="stylesheet" media="only screen and (-webkit-min-device-pixel-ratio: 2)" type="text/css" href="main-highdpi.css" />

2. Create hi-res versions of sprites you rely on and update css sprite references. I don’t believe the preferred naming convention is agreed on yet (postfixing the resource name with @2x seems popular e.g. main.png & [e-mail])

3. Profit!

I would advocate such an approach because of the higher rendering quality of raster images (as opposed to scaling with background-size), lack of compatibility issues and faster client-side rendering. The downside is transferring bigger image files which is an acceptable price to get a hi-res image onto the client device (and the sprites will be cached anyway). At least you do not end up requesting both copies as this article suggests!

Just be sure to keep in mind individual device limitations (image size and dimentions etc.).