Beyond Media Queries: Fixing the Pixel Problem

When CSS measurements don’t add up in the face of different sized displays and multiple media queries, turn to typography to solve the problem (and save your design).

It may come as a surprise to many designers that  a pixel—and every other absolute measurement unit upon which we’ve relied when designing for the web—is, and always has been, a lie.

Since the advent of computer displays ranging in size, we’ve been using artificial distinctions to stipulate the number of pixels per inch (PPI). Even with the same monitor and pixel resolution, Apple claims 72 PPI, and Microsoft has stipulated 96 PPI. While we’ve been able to live with this on desktop and laptop systems, the rise of the web and more recently the explosion of mobile devices has made these disparities nearly impossible to reconcile.

What’s even more confusing is that the World Wide Web Consortium (W3C), the body governing development of web standards, has tied all units of measure to that 96 PPI value—but not to the actual physical measurement of one inch. This is supposed to yield a physically standard-sized “reference pixel,” but that actual tie to the physical size has never been implemented. Ever.

Phone and tablet display resolutions have skyrocketed, giving in some cases true HD resolution on a device that fits in your pocket. Yet these devices report resolutions to web browsers far lower, at somewhat arbitrary numbers like 320×480 (iPhone 4s), 320×568 (iPhone 5s), 360×598 (Android-powered Nexus 5) or 800×1280 (Samsung Galaxy Tab S 8.4). Actual PPI on these devices ranges from 326 to over 440. But images can display at their true native resolution—which means that we have web pages that render with the much lower numbers and images that can display at the much higher ones (at the cost of much larger file size—not always ideal on a mobile network).


Photo from Shutterstock

The reported resolution is an artificial set of numbers that differs widely from the actual device resolution—but only for a certain class of devices, namely phones and tablets. As tablets get larger and laptop/desktop resolutions increase, the disparity between reported resolutions and actual device sizes frequently crosses over. When that happens, we have tablets and phones that report half of their true resolution and super-high-resolution laptops that report their true resolution (some Samsung touchscreen laptops and possibly other Windows-based ones). This leads to an impossible set of contradicting conditions for which we must design.

The entire premise of responsive web design is to stop dealing with absolutes and, instead, rely upon more fluid design and development techniques that can adapt to ranges of device capabilities, instead of being tied to arbitrary dimensions. But when the math keeps changing and may or may not map back to realities upon which we can rely, even the most flexible designers can’t find a foundation.

Digging Into the Pixel Predicament

There’s a CSS work-around attempt that includes targeting both screen resolution and pixel density. This is possible with an evolution of the CSS media query specification that adds the ability to target minimum dots per inch, dots per centimeter or dots per millimeter. At least that’s how the specification reads now. With this attempted fix, browsers are still all over the map in their support for this implementation of the earlier syntax of “device pixel ratio,” which maps real pixels to the lower “virtual” numbers by supplying a multiplier. Also, the multiplier is recommended to be a whole number, when in truth it’s often something less precise.

But even this work-around breaks down when the true resolution is very high and is equal to the reported resolution of the browser. This set of circumstances leads us as designers (and developers) to believe that if the resolution is 1920×1080 and the reported device pixel ratio is one, we could only assume that it would be a physically larger device. As a result, our pages would likely render as small postage stamps in the middle of the screen. While this is a somewhat rare set of circumstances, the likelihood will only increase as more manufacturers introduce higher resolution displays in their laptop and desktop systems.

I’m actually a fan of high-resolution displays. They look fantastic, and I wouldn’t want to go back to an old one. But as a designer and an advocate of both better usability and some sense of sanity in the world of web design and development, having to patch together a series of guesses to have any chance of delivering a meaningful experience is just untenable.

Finding the Silver Lining: Type Size

We do, however, have a relatively simple way out of our dilemma, and can rely upon the existing media query solution of viewport size and pixel density for handling images. So what’s this simple solution? Type size.

By setting type in our web pages with a relative unit of measure like the EM, which is based on “font-size: 100%” in our CSS—and setting our media query widths with that same unit of measure—we completely sidestep the issue of pixel resolution and density, simplifying our lives and work in the process.

Viewports describe to what the measurements are being applied (generally the same as the window size for a laptop or desktop system). These arbitrary values are mapped back to the “viewport resolution” that governs how web page are rendered on that given device.


Keeping in mind, of course, that the creators of every device on the market determine what they feel is a reasonable physical representation of “font-size: 100%.” Here are the real numbers: On all desktop machines, “font-size:100%” equates to 16px. Mobile devices do vary, but in general the result is comfortably readable text set in your average default font like Arial, Verdana or Times New Roman. While not an exact measure, this yields a baseline we can then use for specifying media queries and be certain that—relative to the type—breakpoints defined in our designs will behave in a consistent manner.

Setting aside pixel-based image formats like jpeg for the moment, we can base our designs on percentages of width (based on the current viewport) and EMs for text size and margins above and below. While percentage measurements for height have always been unpredictable, the web is a fluid medium. The only place where we need to depend on EMs for anything to do with width is in our media queries—which are relative to the size of our type, rather than the arbitrary and changing number of pixels.

“Design is about communicating ideas and influencing behavior—and that begins with the type you select to convey your message.”

Exploring Real-World Problems

Let’s consider the case of a Samsung laptop. Its screen resolution is 1920×1080 DPI, and its physical measurement is 13.3″ diagonally, corner-to-corner. This yields a PPI value of 165. If your media queries are set to pixel values, the average 1,000-pixel-wide web page would render at about half the width of the screen, and normally readable 16px type would be displayed at an equivalent of just over 9px. This situation isn’t exactly optimal, much less readable. However, text set at 100% in browsers on the Samsung laptop actually translates perfectly in line with other laptop and desktop systems. As a result, your media queries set in EMs will scale and reflow in the same manner they do on more standard-resolution devices.

It’s worth noting here that while the solution proposed is a decent one, and will likely work well for a wide variety of circumstances, it’s not ideal. There exists in the CSS specification units of measure that are supposed to reference a physical reality: inches and millimeters. Yet those are tied to the so-called reference pixel number of 96 PPI—no matter how those 96 pixels are physically displayed.

In current browsers, a box that is set with CSS at 1-inch square will render on my MacBook Pro (non-Retina) 13″ screen as 3/4″ square, on my iPhone 5 as 9/16″ square and in print at 1 1/16″ square. Only when I save that page as a PDF and then open it in Illustrator do I actually find something exactly 1″ square.

If we can get true DPI reported (as is indicated in the specification for media query resolution) and the pixel dimensions of the viewport (easily available in JavaScript and also utilized by media queries), then we should be able to render elements in the browser based on real physical measurements. But for all of the advances in computing over the past two decades, this is one step forward that has yet to be taken.

Designing Relative to Type Size

In truth, no matter the resolution, designing with units relative to the base size of your type is likely the best approach. After all, design is about communicating ideas and influencing behavior—and that begins with the type you select to convey your message. A good typographic system based around the size of your body copy and built up from that point has been a hallmark of good design for decades. Just because it’s being displayed on the web doesn’t mean that this doesn’t still hold true. Once you’ve taken this step, you can build a flexible design system that will scale and flow in a sensible manner on any device, without relying upon fixed dimensions or pixel-bound layouts.

Sometimes we get lucky, and the best solution at hand just happens to coincide with some pretty good practices to follow in your design process.

agile development;Speaking of design process: Wanna work more agile in 2015? The HOW Expert Guide, Becoming an Agile Designer, explores how project management systems and tools can enable you to release work more rapidly and more often.