Beast-Blog.com
Replicating Browser Behavior: Print Function

I had mentioned in a previous article, “Replicating Browser Behavior: The Top Link,” that I named it the way I did with the notion that I might expand it into a series of articles. Following through with that, I am offering a look at another browser function often replicated by web developers: The print function. For the record it isn’t really a browser function, but rather a function of the operating system accessed through the browser. I’m including it in that category, though, so let’s take a look.

In a Windows environment (I mention it because it’s what I use), printing a web page is carried out by clicking “File,” then clicking “Print.” From there the computer’s print interface is launched. I suspect Mac, Linux, or any other operating system’s user interface is pretty much the same. The reason it would be is that this is what people are used to. It’s a long-established convention or usability protocol. It is a matter of usability being design and can’t be dramatically changed without causing a stir.

So common and well-known is this computer function that replicating it might be completely unnecessary. I have no numbers for you, but I strongly suspect the vast majority of computer users know how to print. Despite this, I often see “Print This Page” or “Print this Article” links on web pages (and I’m not being negative about that). The questions are should you and why. So let’s look at the various methods and alternatives and explore what might be the best route to take.

Using JavaScript

To offer this type of functionality, since it interfaces with the user’s computer, server-side scripting can’t be used. User- or client-side JavaScript would be what’s needed. Please note, however, since JavaScript is a client-side scripting type, it means the user must have it installed, enabled, and not blocked by a local area network. Since, as a developer, you cannot guarantee this condition, you need to ensure you don’t rely on this script type. In fact, the best way to handle this is to use JavaScript to add the JavaScript function interface (a link or form input) to the page. I would do this using document.write but that isn’t favored by forward-thinking developers so I encourage someone to offer that solution as a comment. I’m not very JavaScript savvy else I’d share more.

JavaScript Print Function

In its most simple form, one can offer a secondary method of printing the page. This is fine I guess, but it’s truly a replication. There’s no tangible benefit aside from, possibly, user convenience. And perhaps one could argue that it is even more logical and intuitive than the computer’s default offering. I won’t argue the point, but rather let’s look at some alternatives that bring a little more to the table. Moving on…

A Better JavaScript Enhancement

If you’re going to offer something, offer something that is more than a replication. Offer something to capable users (the majority by far) that can safely be called a Progressive Enhancement. An example of a progressive enhancement would be to offer the printing of single-page sections or passages individually, or to offer an images on or off option. These are choices that can’t be offered by a print style sheet. Thus they might actually be of value to the end-user. To see an example of this type of script in action, see my Green Methods site (scroll to the bottom of the selected page to find the two print options as links that open respective print ready pages). There are scripts that offer all sorts of functionality so please provide links to them if you have ‘em, or search out some options if you need ‘em.

The Print Style Sheet

Now, whether you’re offering some sort of cool JavaScript magic or not, the most important thing you can do, what you should do, is to produce a print style sheet, a print CSS. This is the grand back-up plan so that if your progressive enhancement isn’t available, you are still meeting the toner-sensitive needs of your site’s users. A print style sheet is identified by its media type. If you look in the source code of this blog you’ll see this link in the head. Look towards the end of the line:

 <link rel="stylesheet" type="text/css" href="http://green-beast.com/blog/wp-content/themes/beastblog-v2/print.css" media="print" />
 <!--Note the media="print" part of the line-->

Note: I think the use of “link” is better than an “import” statement as it concerns a print style sheet. I believe “link” is more widely accepted and supported for this media type. Please correct me if I’m wrong about this.

If you followed the link in the mark-up above you can see that a print style sheet is a rather simple file. The most commonly used thing you’ll see is the display property none. After all, not printing sections and images, and maybe removing colors, has the most benefit. And if you really want to save people’s toner, unbold headings and make them gray. In my print style sheet, I remove everything except the page heading, article heading and byline, article, and copyright portion of the footer. That is, after all, very likely all that’s needed. Since my images have been assessed primarly as “decorative,” anything else would be a waste of toner/ink — and that stuff’s not cheap! To view this, select “File” then “Print Preview” or its equivalent right now.

As you can see, the print style sheet is rather powerful. It can do more as well. I don’t do it here, but you can add classed divs or other elements to your page used to mark page breaks by specifying the properties of page-break-before and page-break-after, like so:

 .break {
   page-break-after : always;
 }
 /* goes in the style sheet */

 <div class="break"></div>
 <!--goes on the page-->

Print Style Plus Possibilities

I mentioned before that “these are choices that can’t be offered by a print style sheet,” by which I meant you can’t offer the user the ability to choose whether or not to print images on demand, or to print specific sections of a page. Well, that wasn’t exactly true. You can, but you need to change print style sheets first. That part can be done with server-side scripting like PHP thus avoiding the need for JavaScript entirely. To learn how to change style sheets, check out these Google findings.

The Best Choice?

Unless you’re going to have a high demand for printed output, and really need a lot of varied print functionality, I think just offering a print style sheet is the preferred action, perhaps going so far as to try and control page breaks. If you want to add limited functionality, but want it to be as universally accessible as possible, I think using PHP or another server-side script type to change print style sheets to unlock choices might be the best way to go. Don’t misunderstand me, though, I have no “issue” when it comes to offering additional JavaScript functionality if done properly and purposely. If it’s being done because you can, that might be another matter.

I’d be interested to learn how you weigh in on this subject. What do you do? What’s best? Can print solutions create issues or does it solve them? Or maybe you just want to print this page, huh?

Filed under Access Counts, Coding & Markup —

Bookmarking Links » del.icio.us | Digg | blogmarks | StumbleUpon | Technorati |

These posts may be related:

Replicating Browser Behavior: The Top Link »

Accessible Smart Tables »

Interview with Sigmund Gnoskrept »