With all of the devices available now, it may seem that developing and testing is a nightmare for your web project. The amount of screen sizes to think about is a lot more diverse than the older days of mostly 1024px monitors. But what complicates things further is that these devices have different pixel densities. There ends up being more vocabulary and marketing that complicate the subject.
Wait, my Samsung Galaxy S4 is not 1080x1920?
“Retina” or HD phones promote “desktop” screen sizes and yet when you look at websites on those phones the visual space is still around 320px minimum (360x640 for the S4). “Desktop” screen sizes aren’t simple to account for either because the size is not actually your viewport size. With all of the caveats and terms out there it can be easy to lose yourself in what sizes to design and account for. That’s why it isn’t surprising that lately, I’ve been hearing confusion from clients and developers about this. Hopefully I can help clear this up a bit and give some advice to simplify things.
Screen vs. Window Viewport vs. Client Sizes
First, let’s take a look at “desktop” screens to get into the caveats of terms and sizes. If we follow most common screen sizes you might have a higher chance of viewing this post on a screen size of 1366x768px which is really common in laptops, hence quotes around “desktop”. Does that mean your website will show at that exact same resolution? Yes, but only if you are truly in a full windowless screen that doesn’t show scrollbars. However, for most users, the answer is no.
Many web browsers over the years have tried to cut down as much outer border and toolbar heights as possible. However, don’t forget that if you are in a window those add their own borders and that varies between operating systems. So now out of that 1366px of width you’ve maybe lost ~16px of space due to the way your OS styles windows. What confuses some people is that some resizing extensions for development include that into their calculations, so if you’re trying to test for a 1280px screen the resulting width would actually be ~1266. However, your users might be full screen so they would have 1280px and not 1266.
It unfortunately isn’t that simple either because now we need to account for the scrollbar that might or might not be on your browser. This is where window size and actual client content space can differ. That same resizing extension now tries to account for scrollbars and depending on OS, browser, etc.- it might remove another ~17px of space. Now that resized screen space is only 1248px wide. This is the difference between your viewport width and your actual potential content space. This is also why there is a difference in Javascript between window.innerWidth and document.documentElement.clientWidth. To throw one more in there, this is why auto margin on an image is potentially aligned differently than a background image with 50% centering.
To summarize, let’s say you have created an image and set it to be 1280px wide. This image might look cut off or will shrink down for actual 1280px users because of all of these differences. Not to mention that not all users browse using their full screen size, so it could be any size up to 1280. Don’t get me started on heights because that can fluctuate even more due to how many toolbars a user wants!
In not so many words:
Screen = 1280
Application <= 1280
Window <≈ 1266
Content <≈ 1248
Viewports, CSS pixels, and the “Mobile” World
Now that responsive has pretty much overtaken the web development world, breakpoints have become an important tool in getting your website to look good in so many different screen resolutions. This “mobile” world has been where all of these different viewports and screen sizes started popping up. The main clarification here that I hinted at before is that Pixel Densities are the difference between “native pixel” size and “CSS pixel” size. You’re in luck that breakpoints all revolve around CSS pixel size because it means you don’t have to worry about all of those large native pixel sizes. The CSS breakpoints on your website today will still probably hold true for the 4K screens of tomorrow and you will still see some common screen sizes like 320px and the like. Your viewport is more or less the window size so those numbers would be returning the same info in Javascript. Smaller screens don’t have scrollbars - so generally your users will get some consistent content spaces.
Well not quite.
Do note with screen docking and various window sizes your users could be seeing those smaller screens with scrollbars. Also, the phone sizes are getting larger with “phablets”. So we are back at the confusion of users, clients, and developers on why their 320px docked screen has different content space or breaking issues but not in their phones.
This brings me to the advice part.
Advice for Future Sanity
It’s time to let go of an exact device and screen size development mentality as well as the pixel perfect concept. Don’t focus entirely on what devices are viewing the site now but rather all screen sizes in a range. The reason I use “desktop” and “mobile” in discussion with quotes is to make sure everyone knows what I’m talking about. What I prefer using is “small”, “medium”, and “large” with some “extra“ versions for the extremes. Those are the general ranges of sizes you really need to worry about, and it’s good to focus on the lowest common denominator of those, which is “small”. If you can make those look good with some breathing space (since content isn’t pixel perfect) you’ve probably future proofed your site just that much more. From there you can enhance your site as you get larger in a form of progressive enhancement. We don’t know if more users will start using docked windows on laptops next year or what new wearable will come out. So, keeping those unknowns in mind and these caveats of the terminology, you should be set for at least…a year.
