Replicating Browser Behavior: Print Function

Posted May 7th, 2007 by Mike Cherim

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? ;)


11 Responses to: “Replicating Browser Behavior: Print Function”

  1. Tommy Olsson responds:
    Posted: May 7th, 2007 at 3:06 am

    As you know, I’m not too hot about duplicating features that are built into browsers. There are cases when you need a ‘print version’, e.g., for pages inside a frameset or for articles that are split into multiple parts. In those cases, I think it’s fine to have a ‘print version’ link, but I still don’t see much use for a ‘print this page’ link. But that’s my personal opinion.

    If you have to have such a link, though, I think it should definitely be created by JavaScript since it requires JavaScript to work. In an HTML document you can do it with document.write(), but that option is not available for XHTML, where you’d have to use document.createElementNS() (preferably in an unobtrusive way).

  2. Sri responds:
    Posted: May 7th, 2007 at 2:55 pm

    Probably the easiest way to add the in-line “Print” link with Javascript, that would work in both HTML & XHTML (with various levels of strictness), would be to include the link/button in the markup by default, but have it styled in CSS so that the user can’t see it (visibility = “hidden”). Then in the body onload, use javascript to change the style to show it (visibility = “visible”).

    ie.
    document.getElementById("printbutton").style.visibility = "visible";

  3. Jermayn Parker responds:
    Posted: May 7th, 2007 at 9:33 pm

    Agree with you and I think that you should just include a print stylesheet, I have heard arguments that it is part of the usability and accessibility code to include print page on every pages but I do not see the point and see that as unusable and unfriendly due to what already has been said…

    Thanks :)

  4. Tommy Olsson responds:
    Posted: May 8th, 2007 at 1:04 am

    @Sri: that may be an easier method, but it has its drawbacks. It would show the link in Lynx and other non-CSS browsers, for instance.

  5. Robert Wellock responds:
    Posted: May 8th, 2007 at 8:31 am

    Usually the best solution it to have a linked CSS Print Profile; surprisingly most people never even bother to use print preview so you don’t want them to go crazy hitting the print commands.

  6. Tommy Olsson responds:
    Posted: May 9th, 2007 at 8:46 am

    @Mike: No, they are very different.

    document.write() writes to the response stream and is used ‘in place’. That is, the output from the function call is written at the place where the SCRIPT element exists.

    DOM methods like createElement() (HTML) and createElementNS() (XHTML, XML) modify the DOM tree. They are usually not invoked until after the whole document has loaded, i.e., when the DOM tree is complete. The best way to implement this is through unobtrusive scripting: an external JavaScript file linked to in the HEAD of the document. The external script assigns an event listener for the window object’s load event, using addEventListener() (modern browsers) or attachEvent() (IE). That event listener will then modify the DOM tree, in this case by creating a new anchor element and inserting it at the appropriate place. Then another event listener is added for this new element, which captures the click event and calls window.print().

  7. Stevie D responds:
    Posted: May 11th, 2007 at 12:14 pm

    I have used document.write in the past (largely through not knowing any better), but I like Sri’s way better.

    IMX, the reason most authors put a “print page” link on is because they have not linked to a print stylesheet, but instead have to generate a separate version of the page adapted for print. Definitely not good practice!

    One website I run displays on screen as white text on a dark background - it has had a print stylesheet for years with black text on white. In all that time, I’ve had just a couple of people email me to ask if it would be possible to generate a “print friendly” version of the page so they wouldn’t waste all their printer ink - other people have either guessed, worked out or hoped that it would print black-on-white - or haven’t thought about it at all.

    In general, I don’t like the idea of using “print this page” links, because it does just replicate the browser functionality. However, where there is a significant difference between the screen display and the printed page, such that users might expect to see a “print” link, it may be useful to add one. I’m torn. Do we perpetuate and exacerbate the bad practice of holding users’ hands too much, or do we try to make the world a better place but possibly hinder a handful of users’ experience of our website?

    The time it’s worth offering a “print page” is when an article or document is split over several pages - the printable version can then pull all the pages into one document for ease of printing. This could also be offered as a “print or download” version, for people wanting to read offline.

  8. BillE responds:
    Posted: May 13th, 2007 at 9:30 am

    BTW, “page-break-after” doesn’t work on most browsers yet. You might want to mention that.

    Also, “import” works on all 4.0+ browsers. It doesn’t work on pre-4.0 browsers. It has nothing to do with whether “link” is better than “import”. People use “import” when they have CSS that they only want 4.0+ browsers to see. Older browsers can choke on some of the more advanced CSS properties. You can then use “link” to provide a basic level CSS. The 4.0 browsers will see both, which works fine if you set it up in an organized fashion.

Sorry. Comments are closed.




Note: This is the end of the usable page. The image(s) below are preloaded for performance only.