Skip to main content

Pixels are ruining my life

By Lyza Gardner

Published on April 23rd, 2012

Topics

It’s been a strange few years for the pixel, that unit we love to hate and generally blithely use anyway.

First, there is the weird brain-bending device pixel versus CSS pixel math we’re all trying to do in our head since we started seeing a lot of high-density digital displays on the market.

Then there’s the whole schizophrenia in the standards worlds about what a pixel even is. Ask the W3C currently, and you’ll get a wholly incomprehensible definition (kind of fun as a drinking game/party laugh) that in the end claims "absolute unit." Ask the Mozilla Developer Network, and you’ll get a brief answer of "relative."1

The reference pixel is the visual angle of one pixel on a device with a pixel density of 96dpi and a distance from the reader of an arm’s length. For a nominal arm’s length of 28 inches, the visual angle is therefore about 0.0213 degrees. For reading at arm’s length, 1px thus corresponds to about 0.26 mm (1/96 inch). —Excerpt from the W3C definition of a reference pixel

And this all before we’ve even reached the lively world of viewports: layout viewports, visual viewports, viewport scales. And the different treatment by browsers of zooming—Webkit browsers don’t really scale pixel-based units after a zoom, Mozilla and Opera do. @ppk may understand pixels2, but I think he may be superhuman.

So, pixels may be relative or absolute, big or small, device-specific or theoretical. Here’s the rub at this point: I don’t care.

When I wrote the post about The Ems Have it (em-based media queries) a few weeks ago, I was mostly just focusing on the surgical problem of getting Webkit browsers to behave, when you get down to it. I spoke of practicalities: em-based media queries don’t break when you zoom.

But whether or not pixels ultimately do scale in Webkit browsers is beside the (deeper) point. If we’re staying true to a "content first" maxim, it follows, logically, that our media queries—as well as our layouts overall—might benefit by being subordinate to the content itself.

From my perspective, ems are more true to content.

For me, thinking in pixels for media queries ties me into some bad habits. I start thinking as if there is some 320 x 480px inviolable "mobile smartphone" reality that we can rely on. On the other hand, 30em is a readable column width regardless of the surrounding pixel complexities.

We’re moving further into a world where content is king, and we know it needs to "flow like water." The containers we build to hold it can likewise be based on the proportions of the content itself. Ideal line lengths, space to breathe around text—those are things most naturally derived by using units tied to the text itself. Ems.

The fact that baseline ems tend to be loosely tied to pixels, i.e.: 1em ~= 16px ~= 14pt should help control freaks to unclench a bit. But, as I’ve been arguing for a while now, that control is illusory anyway. Your content has already broken free of its jail cell. You just might not know it yet.

In his talk at Breaking Development Orlando, Ethan Marcotte (the Great Father of Responsive Web Design) mentioned his support for em-based media queries going forward. While he didn’t delve into the specifics of his reasoning, my hunch is that his motives are generally in line with this notion: content first.

So, I’ve done some of the convolutions. I’ve tried to understand exactly what a pixel is in a zoomed viewport on a pixel-dense device vis-a-vis its CSS-to-device pixel ratio. I’m done with that for now. Long live ems.


  1. Sitepoint also says relative. This may be an artifact of both MDN and Sitepoint referencing CSS2.1. This change doc appears to represent the switch between relative (2.1) and fixed (3). I dunno. I can’t really make a whole lot of sense of it.
  2. PPK "A Pixel is not a Pixel" (YouTube)

Comments