I like CSS. I’m thinking seriously of ditching HTML tables in favor of pure CSS page layout. Unfortunately, it feels like almost every site that pushes CSS fills the page with tiny little fonts, and most of them use absurdly wide text columns with no leading. A List Apart uses decent leading and keeps the column width under control, but their “bigger text” stylesheet only produces a significant change if the user has already overridden their browser’s defaults.
Without that, I have to tell Mozilla and IE to increase the text size to 150% in order to read their site comfortably. Most CSS-based sites need to be bumped to at least 120% for me, due in part to their absurd belief that fonts should be specified in pixels instead of points.
No, seriously: “for screen media, points are a horrible choice” — Eric Meyer. Apparently Eric (who is also responsible for the excellent css/edge site) lives in a world where everyone views the web with the same monitor at the same resolution, through the same perfect eyeballs.
Or does he? The main stylesheet for css/edge doesn’t specify any absolute font sizes at all. Everything is based on percentages of the user’s default font size, which actually makes sense. It is, in other words, resolution-independent, something that is also true for typographic points.
So why does he oppose the use of points on screen? Because the unit of measure that existing browsers call points isn’t resolution-independent, and doesn’t reliably produce the same results as specifying “12-point Times” in a word-processor. He (and everyone else who specifies text in pixels) is working around browser bugs, the same sort of thing that embracing web standards is supposed to move us away from.
To me, the philosphy behind css/edge demands that I specify fonts in honest-to-Goudy typographic units, and that I file bugs for any browser that interprets them incorrectly, on any platform. This means that I consider the common “text zoom” feature horribly broken, because it doesn’t consistently scale the other text settings to match. It would be one thing if it never scaled width, height, or line-height, but doing it inconsistently is worse than not doing it at all.
While I’m on the subject, Mozilla’s “minimum font size” feature seems to completely ignore line-height, which replaces tiny little fonts with overlapping lines of text. Way to improve readability, guys.
So, from now on, my table widths are specified in pica (which Mozilla’s text-zoom doesn’t scale), but the width of the DIV containers for my text content are specified in em (which does get scaled). The way I’ve laid things out, zooms of 120% or so still look reasonable in both IE and Mozilla. People who actually like tinyfonts are free to view this page at 75% zoom.
The only remaining wart is the bitmap logo in the upper left corner. Real Soon Now, I’ll be converting it to SVG. It’s a standard, it’s resolution-independent, it’s rapidly gaining support on a variety of platforms, and it has a strong appeal for old-time PostScript hackers like me. Soon the only things specified in pixels on my sites will be the photographs.