Fixed layouts doomed to fail
June 4, 2001
June 13: I'm disappointed to say that lot of people have
grossly misinterpreted this column, so let me make it completely
clear up front: yes, the Opera sizing thing is a bug (the right
interpretation of px units on a silly interpretation of pixel
density), otherwise it would apply to things other than font sizes.
However, Opera's misinterpretation of the Mac OS's approach to
screen density is a timely reminder that the CSS px
unit is a relative, not absolute, unit. Therefore we should be
aware that forcing rigidly defined layouts for web pages is futile,
given the diversity of web-viewing devices. It is ok to use
px units, just don't expect them to be
fixed-pixel.
I owe Opera Software an apology. In a previous
column, I complained that their preview-release browser for the Mac
showed text too small when styled using the CSS font-size property
with a value expressed in pixels (px). For example, the
sidebar text on MacEdition’s pages is set to 11px. It
looks exactly the same size in Internet Explorer, Netscape, iCab, Mozilla,
OmniWeb and Opera for Windows. On Opera for the Mac it looks smaller
– more like 9 pixels. I had been influenced by the conventional
wisdom, expressed at standards-aware design sites like AListApart. The gurus had
said to use
pixels, not points, ems or percentages if you wanted control over type
size, and I believed them.
We were all wrong. I have looked at the CSS specification carefully, and also checked Eric Meyer’s new book on CSS2. Opera does it right and everyone else does it wrong. This is hardly surprising: Opera’s Chief Technology Officer, Håkon Lie is on the W3C’s CSS Working Group and was one of the authors of CSS1 and editors of CSS2. He should know CSS as well as anyone.
So, what does the spec say?
Pixel units are relative to the resolution of the viewing device, i.e., most often a computer display. If the pixel density of the output device is very different from that of a typical computer display, the user agent should rescale pixel values. It is recommended that the reference pixel be the visual angle of one pixel on a device with a pixel density of 90dpi and a distance from the reader of an arm’slength. For a nominal arm’s length of 28 inches, the visual angle is therefore about 0.0227 degrees.
Therefore, a CSS
px is not the same as a real physical pixel on your screen;
it’s a notional pixel. If the device showing the page has a
resolution radically different from 90 pixels per inch, then physical
pixels could be very different from notional CSS pixels. If you print out pages
from sites without print-media stylesheets, you should be glad that
px doesn’t always translate to physical dots. Try and
imagine 11px text on a 1000 dpi laser printer –
you’d need a microscope.
This isn’t an issue for Windows users, since Windows assumes 96 pixels per screen inch; the difference between screen pixels and CSS pixels is therefore small enough not to be noticed. On the Mac, though, the operating system specifies 72 pixels per inch, so one CSS pixel should be 20 percent smaller than a screen pixel. Opera is the only browser that does this according to the specification, but nobody noticed until its Mac version came out; the other browsers’ behaviour fitted better with what designers wanted. You could argue that 72ppi isn’t different enough from 90ppi to warrant this behaviour. You could argue that most Mac screens have resolutions higher than 72ppi and that Opera shouldn’t have followed the OS’s assumption. In any case, Opera is inconsistent in that it seems to show width and height pixel lengths at 72ppi. I welcome different interpretations or corrections, but this is how it seems to me.
Web designers the world over are probably now despairing that their designs
will ever look the same, even across the modern browsers. By contrast,
I’m quite relaxed about it. The last thing I want is for CSS px units to map to
physical pixels when the ultra-high-resolution screens displaying at 200ppi
or more come out of the labs and onto the market. Opera is doing us a
favor and helping us to let go.
Don’t freeze me out
The whole fixed-pixel business is a mirage anyway. Attempts at content placement still hit a myriad of bugs even on the latest browsers. Even if it worked, I’m starting to think it’s misguided.
Fixed-pixel layouts assume too much about screen resolution, window width and type sizes for comfortable reading. We Mac users are only just starting to be free of Windows-based designers’ prediliction for teeny-tiny screen fonts specified in points. This positive development is partly because newer Mac browsers conform to the W3C/Windows norm of assuming 96 points per inch. But still, too many designers try to override Windows IE’s ungainly default text size, to the detriment of the users of Macs and other platforms.
By now, the old-fashioned table-and-font-tag hackers are probably sniggering at how the CSS “promise” of designer control over page presentation has failed. They shouldn’t laugh. Font tag sizes were never fixed and always scaled according to users’ default font size. And fixed-pixel tables – so-called “ice” layouts – never really lived up to the name. Even in HTML, not CSS, table height and width attributes are only “presentation suggestions,” and browsers can and frequently do ignore them, especially if the table has merged cells. For example, on the MacEdition site, IE/Windows and iCab often expand the green cell with the ad banner in it if a story is shorter than the contents of the orange sidebar.
The real solution is to let go of fixed-pixel design styles. They assume too much about the machines your users have. The Web is not the right medium for such attempts at control. People will view our content in many ways using many devices. It’s time we let them do that.