We all use 72 DPI as a defacto standard when creating web graphics (actually, “PPI” is the more appropriate acronym but rarely used). This used to be the actual resolution of monitors, but slowly over the years this has ceased to be the case. Take my iMac. The screen, straight across horizontally, is 22.5″ and has 1920 pixels. That actually comes out to about 85 pixels per inch, not 72. When we design and test website all on the same computer/monitor, everything looks fine, just like we designed it. But when we hop over to a different computer that has a different resolution, there can be dramatic differences!
When viewing a design on a monitor with a higher resolution the design will look smaller.
When viewing a design on a monitor with a lower resolution the design will look bigger.
Say I design a nice website that is 800px wide on my 85 PPI monitor. Then I view the same exact design on a monitor with 100 PPI. Those same 800px take up less physical inch-age on the higher resolution monitor because the pixels are literally smaller. There are more of them packed into that same inch as on my original monitor. The same is true in reverse, if I were to go look on a 72 PPI monitor the design would appear to grow.
This is no longer fantasy or speculation. Reader Denzil Rowe pointed me to a recent article on Apple Insider where Apple is talking about how this issue is coming to the operating system itself. It’s not only the web that faces these problems, but literally anything that appears on your monitor.
Some new Macs are shipping with monitors above 100 PPI. The difference between 100 PPI and 72 PPI is quite dramatic. Anything that is borderline-too-small when looking at a design on a 72 PPI monitor will likely be totally unreadably small on a 100 PPI display.
So what is the solution? Short term, just be aware of the difference and don’t design things too small if you are still on an older 72 PPI monitor. Long term, resolution independence.
Dave Hyatt wrote extensively on the subject a few years back.
The natural way to solve this “high DPI” problem is to automatically magnify content so that it remains readable and easily viewable by the user. It’s not enough of course to simply pick a pleasing default, since the preferences of individuals may vary widely … The full solution to this problem therefore is to allow your user interface to scale, with the scale factor being configurable by the user. This means that Web content has to be zoomable, with the entire page properly scaling based off the magnification chosen by the user.
In other words, zooming is part of the solution, and we’ve seen this as a trend in all recent versions of major browsers. The problem with zooming, as is abundantly clear the first time you ever do it, is that images look like crap when you zoom them larger than they were created.
SVG (Scaleable Vector Graphics), is the likely contender for an image format that will help us battle scaling problems. But with new formats arises all the typical problems. Will all browsers support it, and in the same way? Does the CSS spec need to change to accommodate it? How will it degrade? And on and on.
Dave’s article shows code samples of how we might have a “high resolution” version of our sites for browsers that support it:
div {
background: url(tiger-low.png);
background: url(tiger-high.png) (100px 100px);
}The future is upon us! Although it feels like it will still be a while before the mainstream web is ready for day-to-day designers to be worrying about this stuff.
On a related note, did you know that pixels in CSS aren’t necessarily equal to a screen pixel?
That Apple Insider article is 2+ years old.
This is a great discussion to have, because as you say — it’s pertinent now.
There’s one other “resolution independence” scheme I want to see addressed. I’m switching from a 1024×768 monitor to a newer, bigger one. Currently at that lower resolution, I know what it’s like for pages to not fit, be harder to read, etc. It’s a very low DPI screen, which makes things worse. However, the worst problem of all — it’s not widescreen, and the new one will be.
How about handling that? One style for widescreen to utilize the horizontal screen real estate, and one for 4:3 monitors? That’d be great.
Screen resolution seems to be a reoccuring subject with every client. That and browser cache. I do hope svg’s gain more support in the future.
One little thing to remember: monitors do not change the pixel size when you change resolution. They interpolate to a resolution you choose which is either bigger or smaller than the monitor’s native resolution and make it appear they have changed resolution. Native resolution is the true pixel size of any given monitor and typically provides the sharpest image. So trying to factor ppi is just as difficult as knowing what resolution your visitors typically choose. It’s a best guess scenario.
This will be a big ‘can O worms‘ moving into the future as resolution independent displays and OS’s come into play. Makes me wonder if we should be doing websites with layouts in em’s that can scale better? The old Fluid designs of the past few years might be the future. Oh well, what goes around comes around. Layout of a website is always an exercise in choosing what we think is best for largest number of users. An interesting topic! Thanks for bringing it up!
The biggest porblem after screen resolution is for me the color profile in images. It is for me hard to find the right color profile. Because whenn i type for example #34ff23 the color looks different on different displays and if the display the same different on xp, linux, os x and vista. Did you know that safari renders colors for png different than other browsers ? I fix that with a css hack for color correction or try not to use png.
This whole issue was driven home to me not by seeing one of my sites on a monitor with very HIGH resolution, but seeing it on my friend’s parents’ monitor. They had their resolution set so low (they are in their 60’s) each letter was like a quarter of an inch tall. Every site required a lot of horizontal and vertical scrolling.
Is there any way to detect not the native resolution, but the effective resolution of a user’s monitor?