Print CSS vs. Printer Friendly Format
It used to be that the way I created the printer friendly version of a page was with a logical step inside of my header and footer. See, most of my pages include a header and a footer template:
<!--- Include header template. --->
<cfinclude template="_header.cfm">
<!--- CODE. --->
<!--- Include footer template. --->
<cfinclude template="_footer.cfm">
Then, inside each of those, there was some sort of CFIF statement to determine whether or not that header / footer should be for standard viewing or for printer friendly viewing. For example, the _header.cfm file might look something like this:
<!--- Check for header type. --->
<cfif StructKeyExists( URL, "printfriendly" )>
<!--- Print friendly header. --->
<cfinclude template="_header_print.cfm" />
<cfelse>
<!--- Standard header. --->
<cfinclude template="_header_standard.cfm" />
</cfif>
This was all good and fine and very easy to code. But then, I learned about print CSS, and suddenly my whole view of printing changed. Now, I don't even need a print header, I just need a special media CSS file that only gets applied to the content when someone goes to print. How easy is that? I was as excited over my new discovery as a kid that just found out about late-night Cinemax.
But, what I've come to realize over the last few months is that Print CSS files are not as easy and exciting as I thought they would be. Print CSS can require you to change a LOT of styles to deal with fixed width pages, hiding ads, altering block level displays to allow pages to wrap properly in IE. And, often, when you change the code, you have to remember to update something in the print CSS to override what ever you just changed.
I could be wrong; it could be that I'm only remembering the good things; but, I feel that these were the kind of problems that I rarely faced when dealing with a print-style header and footer includes. While, it might at first seem like there are more files to have to keep track of, it is actually easier because the cohesion of functionality is greater - all the print related features are packaged in specific header, footer, and CSS files that don't much overlap with the standard CSS / HTML at all. This was more files, but better organization.
Then, last week, I was reading through one of my favorite fitness sites, Testosterone Nation, when I had a realization: print CSS is NOT the same thing as printer friendly. See, at the bottom of all the T-Nation articles, there is a "Text" link that opens up a page that has only the primary article: no navigation, no peripheral images, no ads - just the title, the text, and a small footer. I like to print these articles out and read them at home in my spare time, and, when I print them, I only use the Text link at the bottom - I never ever try to print out the standard article view.
As I was printing one article, I had the above realization and then I came up with this analogy - print CSS and print-friendly pages is like having one watch that is water-resistant and one watch that is water-proof. While the functionality of these two wrist pieces overlaps, the primary goal is different. Water-resistant watches are for every day life in which you may encounter water, either partially or fully submersion, but certainly, this is not something that would be thought of as the norm. Water-proof watches, on the other hand, have been optimized to spend a tremendous amount of time in the water, to be constantly submerged even. Water-proof is optimized for water; water-resistant is built to deal with water in a limited fashion.
The revelation I had was that it's the same for printing. Print CSS is meant for standard web pages that happen to be printed occasionally; they are meant to increase the quality of the haphazard printing of random pages. Print friendly headers and footers, on the other hand, are optimized for printing and should be included when someone wants to make 100% sure that a page can be printed with extreme formatting control. Very much like the water-proof / water-resistant wrist watches, these two printing functions overlap, but are optimized for two different purposes.
So, what can I take away from this revelation? I now believe that best practice is to have a print CSS for every site. Just as we design pages to degrade gracefully, we can also design pages to print gracefully - print CSS is just part of standard development. Printer friendly pages, on the other hand, are a completely separate issue and are to be a specific business requirement requested by the client (or to be provided as a print feature NOT tied to File >> Print).
Want to use code from this post? Check out the license.
Reader Comments
I would say, grasshopper, that you've only made it half-way across the river.
Print CSS can be used just as effectively as print-friendly headers and footers. However, Print CSS should never be applied to your web design, inasmuch as it should be architected into your web design. That is, trying to back-convert an existing web design to include a Print CSS is going to be a miserable experience for all of the reasons you've discovered. However, if you build your Print CSS at the same time that you are building your Screen CSS (and, these days, your Handheld CSS, right?), you won't have any problems.
But what if you don't have the luxury of a complete redesign?
To further you on your path to enlightenment, I want to say one word to you. Just one word. "noprint".
Okay, maybe one word and an example:
In your CSS: @media print { .noprint { display: none; } }
Then, in your html: [foo class="noprint"/]
That one selector can do the absolute bulk of your Print CSS work. Instead of trying to add a bunch of crap into your print.css file, and single one thing out at a time, come at it from the reverse: add "noprint" classes to the display code for the things you don't want to print. This method is forward-compatible, in that you don't ever have to maintain it or remember it.
HTH,
-R
Rick's spot on with his comment. If you've got a good CSS layout, the Print CSS should flow alongside your standard screen display.
When we rewrote UnitrinSpecialty.com, one of the main Business Requirements was that any page should print cleanly. When the QA department tested any new page or feature, they had to also test how the contents looked when printed.
Even when you don't have the luxury of a full rewrite, you can make use of a Print CSS. I added one to my blog so that any entry could be printed without the side navigation and other elements. I also tried to get the entry content to fill more of the 8.5" x 11" print area. I think the footer still floats around a bit, but I'll nail that down later.
I use PDF generation in CF8 for all my 'print' versions.
Umm . . . Matt . . . what if user doesn't have any applications that can open PDFs files? Yes, I know PDF readers are easy to obtain, but there will inevitably be users who don't have these on their computers for some reason.
@Rick,
That .noprint suggestion is just brilliant! Holy cow. I love simple solutions to stuff that just seem so graceful.
Last night, I was having a little talk with Clark Valberg about this sort of thing, and he raised an interesting point - standard users don't know about print media CSS. Users only know what they can see. As such, he had the further suggestion that any "print friendly" link refresh the page, but change the media attribute from "print" to "screen". That way, the user truly sees what is going to print and we still get the same benefits of having a print CSS.
Well, the "print" to "screen" switch sounds good, but it also introduces one more page click to the process. The PDF conversion is an issue as Lola mentioned. If they don't have a reader, they're stuck. If they do have a reader, they have to wait for it to load.
I think if someone wants to see _how_ the page will print, they'd just go to "Print Preview".
In my experience, most users just want to click "print" and move on.
Well said Adrian. I agree. Do note that in "Print Preview" any print CSS media you have defined will render there. It's how I test out my print CSS but I'll at least do one print out to make sure everything is good.
I find the best thing about a print CSS is that I can knock out the navigation | header etc with one line:
#header, #navigation {display:none;}
No server side logic required.
Assuming your document is well contructed, this sort of approach (of hiding whole divs) is amazingly easy.
@Adrian, Javier,
I disagree to some degree there. Now, obviously, I can only speak for myself, but I know that whenever I need to print out something like a checkout confirmation or a Fandango ticket receipt, or even something as simple as a Google Maps Directions list, I always look for the "printer version" of the page because I know that it will print better than just hitting print; half the time when I go to print something straight from the standard view, half the page gets cut off.
Now, obviously, those sites that I have experience with did not use good print CSS (or any for that matter). But, the point I am making is that at the very least, there is a certain comfort level that I have when I see a print friendly link.
And, let's not confuse this with a "print page" link. Print Page links are the dumbest things I have ever seen. These are links that basically do something like javascript:window.print(); That's just retarded. I'm talking about a "print friendly" or a "print view" style link.
But, again, I can only speak for myself. And I NEVER use print preview other than when debugging a site :)
Why code yourself when other have already done the heavy job. An excellent free online service called PrintWhatYouLike can be used nowdays that lets the user easily choose what to print and not to print from a web page.
Lets say that you wanted your users to be able to print this article, just use the link below and let the users choose their own printout setup:
http://www.printwhatyoulike.com/print?url=www.bennadel.com/index.cfm?dax=blog:1107.view
@Raffe,
That service looks really interesting. It seems like you can select the parts of the page that you want to print. I'll have to look more into this.