DPI independent UI for webpages

Question

For almost a decade, before LCD became the norm, screens used to be 72 or 96 DPI (Usually only found on Trinitron displays). However, now 120 and 144 DPI displays are quite common.

With the coming of Windows 7, DPI issues are more or less resolved to some degree for desktop apps, and at least the UI of OS stuff is never broken on a high DPI display.

Now we come to web pages - I had a huge argument with a friend about building a DPI independent webpage - My view was that UI elements should look the same size on various systems, and that every CSS dimension should be specified in inches rather than pixels.

I raised this topic on SO and there was general disapproval about using inches as units, which i find rather -uh- un reasonable.

I have a 144 DPI screen of only 15.4 inch size - The size of individual pixels is so small that text antialiasing and subpixel rendering is really effective, but I see lots of webpages which assume that an 8 point font is big enough to read on any system.

I believe that this is a huge annoyance and a fundamental flaw in UI design... Making assumptions about the users environment when you can actually adjust to the existing one.

It's not very different from the early webpages in the 2000s which would not display properly on 1280x1024 since they were designed for 1024x768

Another irony is that only firefox renders a 1 inch element as 1 physical inch - all the other browsers are off unless your screen DPI is 96 Obviously somewhere in the code is the value 96 hardcoded - How hard is it to replace that with a GetScreenDPI() or whatever API call?

What are your views?

Answer 1

Pixels are a hardware-level concept, and as more pixels are being crammed into less space, designers are going to have to learn to use a different unit of measurement. If I design a button to be 100 × 200 pixels, because I assume a 100dpi screen, a user on a 200dpi screen will suffer since the button will have ¼ the area.

As more devices ship with high pixel density screens, designers will actually have more control (and flexibility) if they know the technical aspects of the systems they're designing for.

For example, specifying web layouts in points is more future-proof since you're specifying the physical size (barring the implementation bugs you mentioned).

As another example, screen coordinates in iOS devices are measured in points, and for older devices without the new high-density screen, there was a one-to-one mapping of points to pixels. The iPhone 4 doubles the number of pixels but keeps the point-size dimensions of the screen the same (so old layouts will still work, but new layouts can use fractional dimensions for higher positional accuracy.)

Answer 2

I think it's better to use percent for UI designing. Then you can put absolute values in body tag. Change body absolute values everywhere required using javascript. then you will have everything else OK.

For javascript part, try to recognize user display and calculate values. its easy.

Answer 3

Why use inches when both graphics and screen sizes are measured in pixels? Different resolutions display different numbers of pixels per inch, so if we measured in inches for margins, padding, font sizes(better to use px or em than pt), etc it would be harder to figure out just how big our images(which are made pixel by pixel) would be on the page. Not to mention that 800x600 resolution is always 800px x 600px regardless of how many inches the screen is.

Part of becoming a web development/design professional(or guru) is learning how to effectively build your site so that as many users as possible can access it. And the techniques required to do so are becoming wide spread and accepted. My point being, if the developer is doing there job, it shouldn't be a problem. And that's one of the reason's this site exists.

Answer 4

unit consistency; real inches. (72 points make an inch)

8 point font i love liberation mono at 8 pt but that's only because it looks so good grid fitted at such a small size -- to me some fonts just look strange when you see their detail but look fine grid fitted

1280x1024 (5:4) and 1024x768 (4:3); you could scale fine from the smaller to the larger but you'd have to rotate the larger screen and if these screens were the same size, a inch layout would work unchanged but there is still two problems: one laying out text for a screen of unknown size and getting the font size right

you can make a page invariant to the resolution of your screen but you can't make it invariant to the size and shape of the screen

i modified mupdf (a pdf viewer) to default to real size as under x11 the server provides the real size of the screen and its resolution reported for my screen by xdpyinfo as:

dimensions:    1280x800 pixels (301x192 millimeters)
resolution:    108x106 dots per inch

(although if you want the working area dimensions you have to read a property defined by the Extended Window Manager Hints: _NET_WORKAREA(CARDINAL) = 0, 25, 1280, 744)

but i found that the screen was too short and that meant you had to scroll in pdf pages -- i rather like paged media but one should never mix paging and scrolling

and then i went on to think about getting a screen that isn't shorter than a letter page such as a portrait mode 21.5in lcd (but it's hard to find an lcd of that size in the 108+ dpi range for no more than 250 us)