Handling High-Resolution Screens on the Web

A lot has changed recently with the development of more and more high resolution and retina screen devices. We as web developers need to make sure we stay equipped to present the best possible option for the device. In that vain, here is a quick code snippet that demonstrates how to handle high resolution raster images and a story about how I came upon it.

/* Pixel ratio of < 1.5. 
Background-size is set to the CSS pixel size, 
thus condensing the high resolution image */
 
@media only screen and (-moz-min-device-pixel-ratio: 1.5), 
only screen and (-o-min-device-pixel-ratio: 3/2), 
only screen and (-webkit-min-device-pixel-ratio: 1.5), 
only screen and (min-device-pixel-ratio: 1.5) {
 
  .m3background {
    background-image: url("highres.jpg");
    background-size:640px 480px;
  }
 
}

Here’s my story:

Recently, a client requested that I make branding updates to their website.  They sent me over a decent EPS image (albeit somewhat bitmap hacked) for the branding update.

Now I have a decision, do I spend the extra time to make this look great on retina screens and will anyone care if I do? …or… Do I save out the PNG image and get it up there so that we can get their branding launched ASAP.  I chose the latter, we launched it, and sure enough, “it looked blurry”.

A couple days after releasing, I hear from one of the major stakeholders, “The logo looks blurry.”

After pondering for a minute I realized something; of course!  He’s on a retina screen!  High resolution screens aren’t just the iPhone anymore, and they aren’t just iPhone and iPad anymore.  Retina screens now encompass the MacBook pros we work on every day!

Here is the PPI for some common devices:

Anyway, you get the idea, high resolution screen usage is growing.

So now we’re faced with the thankless job of making this look great and there are some problems:

1. Lower resolution graphics look no better on a higher resolution screen.  In fact, for some reason, they look worse.  Try watching a standard definition TV signal on your high definition TV, same problem.  This is especially severe in the web world where we lived in 72 ppi for so long.  I had a healthy debate for why this is with some of our designers.  One contention is that everything else looks crisp (fonts and other aspects of the website layout are vector).  So if everything else looks crisp, and the client logo is a paltry standard resolution, then, well, “it looks blurry”.  The other contention that because the image is essentially getting scaled up the rendering and smoothing gets out of wack.  Either way, it looks worse.
2. Bigger = Slower. We’re undergoing a massive effort to make things lighter weight and faster.  Yes, here comes the retina train.  For the logo improvements I looked through all the possible scenarios, none of the options pushed smaller bytes down the pipe .  Higher resolution versions are larger, and therefore slower to load.  Higher resolution screens are also more prevalent on mobile devices like the iPhone and iPad, where some people are getting changed per megabyte and speed is important. Do those people want to wait longer and pay more to download the same page?
3. A pixel is not a pixel. I’ve had some great fun joking with back end developers about this, it’s one of the front-end challenges of not knowing what is going to compile your code.  Pixels are already different in different browsers, now we’ve thrown in something else: a device pixel vs a CSS pixel.  CSS pixels are abstract units used by the browser to draw things consistently (what!? consistently?) Bitmap pixels, the base pixels for images, have to get multiplied by four to maintain the same physical size on a retina screen, which causes image degradation.

There are a number of options for dealing with these.

Techniques I’m not too impressed with:

1. Scott Jehl, prominent front end guy, has a library called picture fill, that I don’t recommend because, it’s just another JS file that has to run.  Performance hit.  https://github.com/scottjehl/picturefill
2. You can do something similar yourself, using JavaScript to scrape a data- attribute and adjust.  Performance hit.
3. You can down sample. Performance hit.

Technique I Tried:

1. First I tried SVG, why not right?  It’s an EPS source, vector based, SVG should be able to handle it?  Not really.  They cheated on some of the gradients and made them bitmaps.  The exported paths made the file look like one of the letters was cut off.  And once I exported the file it was larger than the high-res PNG.  Tried with a couple designers to get the file down, same problems.  Scraped that.

Technique I Used:

1. Media Query for screen resolution and return the higher resolution size.

I was lucky enough that the logo was already a background, so I added a media query that checks the screen resolution, and then serves a higher resolution logo if necessary.

This technique won’t always work because everything being a background is not semantically correct.  However since this was a background it worked.  The standard resolution screens get the image optimized for them, the higher definition screens get the images optimized for them.  In this case even the high-res file was 7k, so I felt ok pushing it down the mobile pipe (vs the 25k SVG).

High resolution screens are moving out of just the nerdery, even people’s laptops now have them.  Knowing these techniques should help immensely in the web design and web development world.  Be ready.  I wonder what the Google Glass resolution is?