The more CSS based code you write, the more you learn to work (or explain) your way around the bugs and inconsistencies that plaque markup in general. Lately I've been thinking about a particular area of glaring and simultaneously overlooked code which has been becoming more and more of an issue — the use of printer-specific CSS.
ACDSee PowerPack 6.0.3Regressing to paper.
But wait, you say. What exactly is the problem? CSS offers an easy method of altering all of your style rules as you wish, by simply importing or linking the appropriate file.
Well, not quite.
As everyone knows, backgrounds don't print, unless the user turns on background printing for the site. This turns into a huge deal when combined with some of the advanced techniques we use today, like the various image-replacement techniques for screen reader compatibility and CSS-based rollovers.
But that's no big deal, is it? We simply massage the CSS to give us a clean text-based version of the site. In this way, we can provide a clean and optimized version of the site, to deliver the content most effectively, in theory.
Except, that's not what clients want in a print version.
I've run into this more often than not, lately — the client wants to print the site exactly how it appears on the screen. So, that means that all of my carefully placed background images don't show, which means that the site renders in text-only, or that significant parts are missing.
The problems obviously lie in the browser preferences that turn off printing of background images. To get the site to look the same, you turn on background image printing, except it doesn't always work exactly right, and its a difficult preference to find in a certain market leading browser. Asking the user to do this is rather a tall order.
The problem is compounded if you use the various image replacement techniques. Let's say that for the print version, I have switched the rule for the header tags so that nice clean text shows instead. Now if the user has background printing turned on, they get both.
The solution is obviously regression, or bringing the images that have been moved to the background with CSS back inline in the HTML.
But who are we doing this for? The strange thing is, I get the feeling that it's actually really the client who wants to print the site as it is on the screen. They have just paid you a bunch of money to make a site, and now they want to show their colleagues the site by printing it out on paper.
Obviously there's some sort of disconnect here, since the images won't look as good in print. Even further, it's as if people can't quite operate without having something physical to hold onto, or that clients feel as though they haven't gotten an actual thing for their money, even if in reality most users probably don't care how the site looks on paper, as long as the information is readable.
Or do they? Here's an Ask Metafilter Question that Tim and I posed on the very topic. Turns out the consensus weighs surprisingly toward wanting the site to look the same, even if it looks better and/or cleaner.
This isn't a call to go back to the separate file for a print-friendly version, exactly, but it is definitely an area that needs focus when you are discussing the project initially with a client. At the very least, you can save yourself some headache down the road by figuring out what your client requires in a print version.
The problem is that there is a disconnect with using PrintCSS. I see something on screen, I hit print, I expect to see that on my printer.
From a pure usability standpoint, I think print CSS is actually confusing for a lot of folks.
What I do, when I can, is to make a print-friendly page you can see on screen (usually by reloading the content into a new template).
I see 3 distinct advantages to this:
- as a completely different template, I can actually swap in different images/layout write in the markup (instead of just relying on background images in CSS, etc.)
- what the user sees on screen is what they'll get on the printer
- often, people prefer the print-friendly version even if only viewing it on-screen (I know I do on a lot of web sites).
Granted, if you're building a static site, this is difficult to do, but if you are using some sort of basic CMS, I find this to be a much better solution.
How about showing the client that they can press "ALT-PrintScrn" and then paste into Word or some other application. This way the client gets a pixel-perfect printout to show-off around the office without having to "regress".