Responsive Web Design With Physical Units

About The Author

Art director, focused on eCommerce design and development and a fan of flat skeumorphism. Sometimes blogger, novice speaker, creator of the HTML5 Starter Pack, … More about Radu ↬

Email Newsletter

Weekly tips on front-end & UX.
Trusted by 200,000+ folks.

Today there’s no way to accurately design for the Web using physical units, nor will there be for a very long time. But there is a way to design while knowing the physical characteristics of the device. It’s called the “resolution media query”, and it’s been in the specification for media queries for some time. So, how will we use this nifty little feature, exactly? Here’s how.

This post should be titled “Getting Ahead of Yourself.” “…By a Few Years,” actually. Here’s the deal: at the time I’m writing this, early 2013, there’s no way to accurately design for the Web using physical units, nor will there be for a very long time. But there is a way to design while knowing the physical characteristics of the device — or, at least, there will be in the very near future.

Mobile devices
Different devices can have a similar screen resolution, yet entirely different physical factors. iPad (1st generation) has the diagonal size of 9.7", the resolution 1024 × 768 and 132 ppi. Kindle Keyboard 3G has the diagonal size of 6", also the resolution 768 × 1024, yet 212 ppi. Image source: kodomut.

It’s called the “resolution media query”, and it’s been in the specification for media queries for some time. However, while it has been in the spec, that doesn’t mean anyone has actually implemented it yet. Fortunately, WebKit is leading the way and pushing for this feature to be implemented. So, how will we use this nifty little feature, exactly? Here’s how.

The Thin Line Between Queries

First off, I posit that there will be only one use case for a resolution-only media query. Something along the lines of


@media (min-resolution: 250dpi) {

}

has, at this time, only one good use: swapping out low- for high-resolution images. I’ve tried imagining other uses and, as far as I can tell, there just aren’t any. But resolution is not what we, as Web designers, are truly interested in. Since we are designing for humans, shouldn’t we be thinking about the physical side of human data consumption and designing using this kind of a metric? And in a perfect world we could simply say width: 1in and have a one-inch wide element, regardless of the device. Unfortunately, we live in a digital world in which the physical and digital pixels are not the same. We need something to bridge the gap. That something is the resolution media query.

Good. Now that that’s out of the way, let me show you how this one little piece of code can make so much difference that your head will promptly explode. (I take no responsibility for actual blown heads as a result of this post.)

Let’s compare two media-query declarations:


@media (min-resolution: 341dpi) and (min-width: 767px) > {

}

and


@media (max-resolution: 131dpi) and (min-width: 767px) > {

}

At first glance, this doesn’t seem like much of a separation, right? Wrong. The numbers I’ve used are specific to the HTC Windows Phone 8X (the first snippet) and the iPad 2 (the second snippet). By using the resolution query, one can basically separate physically small devices from large devices.

As it currently stands, a query that looks like @media (min-width: 767px){ } will affect both the HTC and the iPad, with no other possibility of separation, because both have a resolution that is 768 pixels wide. In fact, the iPad has a lower resolution, at 1024 × 768, whereas the HTC is 1280 × 768. In case you haven’t realized yet, the problem with all of this is that the iPad is a 10-inch device, while the HTC is a 4.3-inch one. That’s less than half the physical size!

By using the resolution media query together with a width query, we can distinguish between physically small and large devices to adjust design elements and layouts accordingly. While, as mentioned above, screen resolution isn’t really what we are interested in since we use logical breakpoints in responsive design, it is useful to know whether a site is being displayed on a small or a large physical display — e.g. to increase font size or rearrange design elements in the layout. But where do we draw the line between small and large? Quite simply, we can’t. Each of us has to draw the line, possibly on a project-by-project basis, between “This is a small device” and “This is a large device.” As far as ballpark numbers go, I’ve done a few calculations and have developed a theorem that should give you a clearer idea of how this works more or less.

The Physical Size Inquiry Non-Exhaustive Theorem (PSINET)

Here’s the theory: In a combined query, if the ratio between the smaller of the width and height and the resolution, called a PSINET score, is higher than 5, then the result falls in the category of a physically large device. If the resulting number is lower than 5, then it is a physically small device. Devices that score very close to 5 are considered to be medium-sized, close to the physical size of an A4 sheet of paper (21 × 29.7 cm).

Here’s a non-exhaustive list of devices to test the formula above. I’ve listed each device’s score according to the formula, along with its diagonal size, resolution and density, and PSINET score.

Physically Large Devices

Device nameDiagonal size (inches)ResolutionPPIPSINET score
Apple iMac272560 × 144010913.00
Sony Vaio F16.41920 × 10801348.05
Apple MacBook Pro RD132560 × 16002277.04

Physically Small Devices

Device nameDiagonal size (inches)ResolutionPPIPSINET score
Sony PSP4.3480 × 2721283.75
Kindle Keyboard 3G6768 × 10242123.62
Kindle Fire71024 × 6001693.55
Samsung Galaxy S4480 × 8001603.00
Samsung Galaxy NoteII5.5720 × 12802672.69
Samsung Galaxy S IV51080 × 19204412.62
HTC Butterfly51080 × 19204412.62
Samsung Galaxy Grand I90825480 × 8001872.56
Palm Pre3.1480 × 3201862.5
Sony Xperia Z51920 × 10804432.43
Samsung Galaxy SIII4.8720 × 12803062.35
LG Nexus 4 E9604.7768 × 12803182.41
Nokia Lumia 9204.51280 × 7683322.31
HTC One4.71080 × 19204692.30
HTC One X4.7720 × 12803122.30
HTC Desire HD4.3480 × 8002172.21
BlackBerry Q103.1720 × 7203282.19
BlackBerry Z104.2768 × 12803552.16
Motorola Droid X4.3854 × 4802282.10
Sony Ericsson S4.3720 × 12803422.10
Motorola RAZR i XT8904.3540 × 9602562.10
iPhone 54640 × 11363261.96
Apple iPod Touch3.5960 × 6403261.96
Nokia Lumia 6203.8480 × 8002461.95
HTC Wildfire3.2240 × 3201251.92
Nokia Lumia 7103.7800 × 4802521.90
Motorola Defy3.7854 × 4802651.81
LG Optimus One3.2320 × 4801801.77
Nokia N962.8240 × 3201431.67
Sony Ericsson W810i1.9176 × 2201481.18

Medium-Sized Devices

Device nameDiagonal size (inches)ResolutionPPIPSINET score
Apple iPad (1 & 2)9.71024 × 7681325.81
Apple iPad (3rd Gen)9.72048 × 15362645.81
Amazon Kindle DX9.7824 × 12001505.49
Acer Iconia Tab A50010.1800 × 12801495.36
Samsung Galaxy Tab10.11280 × 8001495.36
Motorola Xoom10.11280 × 8001495.36
Asus Transformer Pad Infinity10.11920 × 12002245.35
Microsoft Surface10.11366 × 7681485.18
Asus VivoTab RT TF600T10.11366 × 7681554.95
iPad Mini7.9768 × 10241624.74
Amazon Kindle Fire HD8.91920 × 12002544.72

Is this method of determining device size foolproof? Hardly — that’s why it’s a theorem. It’s based on solid reasoning and empirical evidence and has come about by using the scientific method, but it is not a rule, law or axiom. Take it with a pinch of salt (or, better yet, a truckload of NaCl) and refine it. It is a theorem, a proposition, to be remembered in the future when the resolution media query and our work with it become a mainstay of the Web.

Breaking The Theorem

Like any self-respecting follower of the scientific method, I’ve tried to break my own theorem. Thus, I imagined a freak of a device, 2 inches long and 20 inches wide, putting its diagonal size at 20.09 inches, with a 240 × 40 pixel display, yielding a resolution of just 11.94 PPI. It gets a PSINET score of 2.01, which puts it well into the small device category, even though it’s almost half a meter long. The reason is simple: it’s that 2-inch-wide dimension. Because the PSINET score ignores the longer of the device’s physical width and height, the greater the difference between those two dimensions, the less accurate the PSINET score will be. Sure, this beast of a device is unlikely to ever become reality, but it’s worth understanding the reasons why it would break the theorem.

Device nameDiagonal size (inches)ResolutionPPIPSINET score
ThinLong20.0924 × 24011.942.01

Real-World Applications

Apart from the obvious visual changes and tweaks mentioned above, there are other ways to use the resolution media query.

Enter Enquire.js. For those of you who haven’t heard of it, it’s a very nice JavaScript library that helps you execute particular scripts on matching media queries.

We could use Enquire.js or even just window.matchMedia, which is a native JavaScript method, to differentiate between mobile, tablet and computer users much more reliably than by using width queries alone. Here’s a not-very-polite example using Enquire.js:


enquire.register("screen and max-resolution: 150dpi and max-width: 300px", function() {
    alert('My, what a small screen you have there, Grandma!')
});

Combining media query types with CSS and using a resolution-aware JavaScript library is just the right formula to give us real future-proof control over what I call the “physical Web.” Imagine being able to view a priceless sculpture located in a museum halfway across the Earth on a 1:1 ratio on any device, or shopping for an engagement ring online and seeing exactly how big that 24-carat diamond is. The real-world applications, pun intended, are nearly endless.

In our world of responsive Web design, we’d very much like to provide the best experience to users, whatever their device. In light of the sans-resolution media query above, that task becomes less of a challenge and more a windmill fight. Assigning blame is pointless, because none of us can do anything to change the current ecosystem of devices. Manufacturers will continue to put out devices with resolutions and pixel densities that they’ve pulled out of their butts, and that’s fine — that’s their business. Staying on top of the situation by providing us designers with the tools we need (but can’t easily build ourselves) to create the best user experience possible is the job of browser makers, and I salute the good people at WebKit for spearheading the implementation of the resolution media query.

Further Reading

Smashing Editorial (al, mrn)