Understanding Device Resolution for Web Design and Development
When a new (mobile, desktop, you pick it) device comes out the vendor typically emphasizes the new incredible and mind-blowing screen resolution and pixel density (PPI) they were able to ship with the product.
That’s great, I mean a 5k screen is something pretty cool indeed. But that’s marketing. If you, like me, work in web design and development you know that behind the term “resolution” there’s something slightly more complex than a big number.
So what is resolution really?
Well, we’ve all heard about pixels, the smallest physical element of a digital display device that the eye can discern (which is actually made up of “sub-pixels” — red, green and blue light elements that the human eye cannot see because of how additive color processing works with the human eye). They are of a fixed size, and different devices implement them in different shapes and sizes.
Resolution (also) talks in pixels. More specifically, for vendors it’s those sweet numbers that define the maximum number of pixels that can be displayed on a monitor, expressed as (number of horizontal pixels) x (number of vertical pixels). For example a Full HD screen has a resolution of 1920 × 1080 pixels (or 1080 × 1920 if you’re looking at a mobile device in portrait mode).
The pixel density or PPI (not to be confused with DPI, which is something used in print) indicates the number of pixels per inch on the screen. Apple’s new iPhone X has 458 PPI, while the first iPhone had 163 PPI. The Samsung Galaxy S8 has a screen of 568 PPI.
Those are a lot of numbers, right? But here’s the point: in terms of web design and development the numbers that really matter are others. Not only that, but the numbers that matter to developers, are different to the ones that matter to designers.
Developers
Let’s start with developers. Every time they start a project one of their main concerns is knowing the types of devices they’re developing for and their resolutions, because writing code especially in a responsive environment can get messy if you don’t know the final medium. So, what they need is, among other assets, a list of resolutions expressed in pixels. But not really the pixels we’ve talked about earlier, they need CSS pixels, an abstraction created by W3C specifically for web development that has nothing to do with the device’s actual pixel density and it’s actual hardware pixels in the display. These are the type of pixels that are used in CSS declarations, like
#container {width: 800px;}
Before high-density displays came out developers (designers too) were happy because, 1 CSS pixel = 1 hardware pixel, so those 800px of #container were actually mapped to 800 screen pixels. Now that high-density displays are a thing, there’s a new parameter to consider — the pixel ratio — used as a multiplier to determine how many hardware pixels map to a single CSS pixel.
Let’s take, for example, the iPhone 7.
Apple tells us it has a resolution of 750 × 1334 pixels and a PPI value of 326. If we were to build a responsive website optimized for this resolution we probably would use media queries*, and that is when we realize that something with those numbers (750 and 1334) is wrong (or CSS is broken…probably your first guess if you’re a newbie developer). Of course, there’s nothing wrong with those numbers, Apple isn’t lying and CSS isn’t broken. You just need to consider different numbers.
The iPhone 7 (and more or less every modern smartphone) has a high-density screen, (Apple calls them Retina Displays), with a pixel ratio of 2.0 or, in other words, two iPhone7 screen pixels equal one CSS pixel. The Samsung Galaxy S8+ has an amazing pixel ratio of 4.0 giving it an impressive 1440 × 2960 device resolution. By the way, I’m writing pixel ratio values in decimal notation because apart from Apple (that only uses whole-number pixel ratios), other vendors implement pixel ratios in decimal form, like the 2.4 value of the Microsoft Lumia 1020, or the 1.5 value of the Samsung Galaxy S.
As a rule of thumb, we have:
CSS Pixel = Device Pixels / Device Pixel Ratio
Our media query to work properly has to reference css pixels, so those 750 and 1334 become 375 and 667 respectivly. If we compare them to the physical screen pixels, CSS pixels are basically “reference pixels” or in other words “virtual”.
Designers
Designers, on the other hand, kind of get to play with both “types” of pixels: they should build their layouts keeping the CSS-pixel resolution as reference, while still taking the Device Pixel Ratio into account when exporting assets.
This means that if you design a page with a desktop template of 1280px wide and a mobile template of 320px wide, you should still provide images (icons probably should be in vector format, but that’s another story…) considering the pixel ratio of your target devices.
So if you cater for screens with pixel ratios of 2, the 320px wide hero image of your design would also have to be exported @×2 or 640px.
Here’s a rather complete list of (mobile) device-related numbers: https://mydevice.io/devices/
Oh, there’s a tiny caveat!
Speaking of pixel ratios and resolutions, we must note that there is one little caveat in the transition between device rendered pixels and CSS pixels.
For some devices the screen’s physical pixels don’t correspond to the actual rendered pixels, so that CSS Pixel = Device Pixels / Device Pixel Ratio formula isn’t (always) true, or in layman’s terms that formula is true if we only consider rendered pixels.
For those devices that apply a downsampling to map the actual hardware pixels of the screen delivering assets at the optimal resolution is a bit more tricky since you don’t solely rely on the pixel ratio value. As a matter of fact, if we consider Apple’s mobile products, only the newest iPhone X has a real @×3 pixel ratio implemented, unlike all the ‘Plus’ family iPhones that have a 1.15 downsize applied (and for the sake of simplicity I’m not considering Display Zoom mode).
(*) I’m considering media queries based on ‘width’, not ‘device-width’ since the whole point of responsive design should be to be device agnostic.
