The Web IS Print!

October 22, 2001

One of the standard catch-cries of the Web design community is that the Web isn’t print. I’ve said it myself – we can’t expect and shouldn’t expect millimetre-perfect reproduction of Web pages across different screens and different browsers.

That’s fudging the truth a little. The Web becomes print as soon as you print out the page. The real catch-cry should be, “Screen isn’t print.” We’ve spent so long unlearning the conventions of print design, becoming comfortable with designing for diverse screens, that we’ve forgotten that the Web can be paged media. When Web pages are printed, the old-style print design conventions can be applied again.

Paging all Web designers

In an earlier column, I suggested that PDF should be used if the document was very long and only ever intended to be printed out. This is true, but there are some instances where HTML plus CSS can generate decent printouts even for very long documents. It’s entirely possible to use a print media stylesheet and generate quality printed output, including headers and footers (using the position:fixed CSS style), and with some control over pagination.

You can remove sidebars and ad banners from the printed version of your page with a simple display:none, and change the colors of text and backgrounds to black on white. This even works for tables-based layouts like MacEdition; you can make particular table cells disappear in the printout with a few CSS declarations. You can read more about this in Eric Meyer’s CSS 2.0 Programmer’s Guide which – despite its ugly layout – contains much useful information on Web design for print media.

When you are designing print media stylesheets, a lot of the rules of thumb we’ve adopted no longer apply. For example, on a stylesheet for screen display, using points (CSS pt units) to define font sizes is considered gauche. Because Windows is based on an assumption of 96 pixels per screen inch, 12-point text in Windows is 14 screen pixels high. The Mac OS assumes 72 pixels per inch – that is, one point corresponds to one pixel. So 12-point text takes 12 pixels, not 14, and the 8-point and 9-point text that Windows-oriented Web designers seem to love is completely illegible. So we use pixels for screen-based font display, or ems and percentages if we don’t want to mess with readers’ default font sizes.

All well and good. By contrast, on a piece of paper, one inch is one inch, a centimeter is a centimeter. You can use absolute lengths, and you can use points to define text sizes. (Pixels, by contrast, are not guaranteed to be the same printed out. It depends on how browser developers have implemented one fairly vague part of the CSS spec.) While you need to be careful about making sure your layout works on both US letter-sized paper and the international A4 standard, you can also implement some pretty complex layouts that are millimeter perfect, at least in theory.

Browsers letting us down (again)

Of course, even worrying about this is pointless just yet. Browser support for CSS2 is so cruddy and patchy that many people have never even looked into the browser support for print stylesheets, let alone some of the more advanced features of print media stylesheets. And as usual, the resources that are there focus on Netscape, IE and Opera. That’s fine for most sites, but if you have a lot of lesser-known browsers like OmniWeb and iCab in your logs, you’re out of luck.

CodeStyle has a reasonably comprehensive support table for the big three browsers on Windows. However, its table would lead you to expect that Netscape 4.x supports print stylesheets, when what the site really means is that it ignores them in all cases so you can safely use them and know you won’t get any crazy results in Netscape. The moral is, read the fine print before you take any compatibility chart as gospel! Another compatibility page comes up with a similar finding, and makes it clear that stylesheets with media=screen attributes are applied to printed output as well in Netscape 4. This page is out of date, however. Opera 5 isn’t included, and neither is IE 5.5 or 6, while the Mozilla scores seem to refer to an earlier build. And of course, the minor Mac browsers aren’t covered.

I’ve done some testing of this myself, and from what I’ve seen, Mac-oriented sites are going to find it harder to implement print media stylesheets just yet, compared with sites with a larger proportion of Windows users.

At the time of writing, neither iCab nor OmniWeb supports print media stylesheets, whether as separate files or as @media sections in a single file. Add in Netscape 4.x users, who are more prevalent amongst Mac (and Unix/Linux) users than Windows users, and you have a fair slice of your market who won’t be able to take advantage of “printer-friendly” versions of your pages. I’ve also seen reports that IE5.1 for Mac OS X doesn’t implement print media stylesheets properly, even though IE5 for Mac OS Classic does. This is hardly a surprise; given we haven’t even reached the day where most conventional browsers have full CSS Level 1 support, perhaps Level 2 support is too much to hope for.

For this reason, I haven’t implemented a print media stylesheet for MacEdition. I could do it in a few minutes if I wanted. But until that one-quarter to one-third of our readers using these less-capable browsers either switch or upgrade to future versions with CSS2 support, there doesn’t seem to be a point. As always, it seems we have to choose between implementing new functionality for some users while leaving others out, or creating yet another site-specific solution using server-side technology. So people roll their own using ASP or PHP or whatever. What is it about the Web that causes so much wasted effort?

— CodeBitch (codebitch@macedition.com) is the grumpy cow who does the HTML production for MacEdition. Read other articles by CodeBitch

E-mail this story to a friend