Three Methods for Providing a Print View of a Web Page

Web developers put content online to be consumed, but we have little control over the mediums consuming it. Web pages are rendered on mobile phones, printers, televisions, and their semantic content consumed by a variety of bots, each with their own requirements and best-practices for layout. Here I’ll outline three commons solutions to providing a print version of web page content.

Defining Printer-Friendly Design

First we need to define the differences between design for the screen and design for print. Computer monitors and mobile phones are very different media from paper, even when displaying static content. Screens are backlit, while paper is reflective. Web development for the screen must take into account screen resolutions, while presentation on paper must consider page dimensions and toner consumption.

Jennifer Kyrnin has a definitive list of print-friendly attributes, changes that should be made to web content before outputting it to the printed document. Here are the three I find most important, but the list can get much longer depending on your needs:

1. Eliminate dark backgrounds and darken font colors presented over them.
2. Do something with links, either display full URLs, emphasize the text, or remove them altogether.
3. Remove headers, footers, side menus, and advertising.

Server-Side Solutions

One strategy for handling both print and screen layouts of a web page is to have two methods for building the page on the server. For example, w3schools’ “PRINT” button at the bottom of each page opens a new window/tab accessing the same page, but with an “output=print” variable added to the end of the URL, which the VBScript accesses via a GET method. When the VBScript detects the “print” flag, it builds the page without all the extraneous content.

w3schools Regular and Print View

Pros:

1. Provides a perma-link for users to reference the main content of your page without extraneous information.
2. Provides a primitive type of Print Preview functionality for the user.
3. Setting up your application to display print-friendly pages in this way sets it up to display other cool things, like XML versions and REST services.

Cons:

1. Print view must be turned on manually, doesn’t automatically render a print-version of the page for printers.
2. We are making a return trip to the server, and probably a database hit too, in order to get information we are already displaying on the screen.
3. Provides a perma-link for users to bypass your advertising and menus when referencing your content.

Strictly CSS Solutions

Another technique involves applying cascading style sheets to targeted mediums. In the example below, the first CSS file describes the page display, while the second css file describes the page display for printers specifically:

<link rel="stylesheet" type="text/css" href="screen.css" />
<link rel="stylesheet" type="text/css" href="print.css" media="print" />

Alternatively, you can use the @media Rule with an inline style like so:

<style type="text/css">
@media screen
{
  body {font-family:verdana,sans-serif;font-size:12px;}
}
@media print
{
  body {font-family:times,serif;font-size:10px;}
}
@media screen,print
{
  body {font-weight:bold;}
}
</style>

Using this strategy involves identifying all of the items on the page we don’t want printed and setting their styles to “display: none;” so that they appear on our screen, but don’t appear in our print outs.

Pros:

1. The same URL automatically renders the page in screen- or print-appropriate layouts depending on the device rendering it.
2. There is no “print” button or link cluttering up the page, the functionality is abstracted cleanly away from the user.

Cons:

1. Having a print.css file with media=”print” is a violation of the DRY principle. It leads to maintaining duplicate code. It’s better to use one CSS file and bracket print and view-specific design choices in @media tags.
2. Means having to put ID attributes around all the content you don’t want to display in order to hide it from the print view.
3. Takes some control away from the user, makes it inconvenient for people who want to save your page electronically. I don’t print web pages. I feel it defeats the purpose of using computers. So I like to pull up the print-version of a page in my web browser and save just the article. @media=”print” means I have to File>Print and then save electronically in some BS proprietary format instead of html.

JavaScript Solutions

With some JavaScript-driven DOM manipulation, you can come up with a function that will provide a pop-up window “print preview” that displays just the content on the page that you want printable. The following openPrintView() function accepts the id of the html element you want to display in a printable view. This function then uses the printFormat() function to strip the links out of the text provided it.

<script type="text/javascript">
/**
 * Strips HREF tags from an html string.
 * Can be modified to strip other tags as well.
 */
function printFormat(html) 
{
    var container = document.createElement("div");
    container.innerHTML = html;
    var newHTML = container.innerHTML.toString();
    var anchors = container.getElementsByTagName("a");
    for (var i = 0; i < anchors.length; i++)
    {
        var hrefcontainer = document.createElement("div");
        hrefcontainer.appendChild(
        anchors[i].cloneNode(true)
        );
        var href = hrefcontainer.innerHTML.toString();
        var text = anchors[i].innerHTML.toString();
        newHTML = newHTML.replace(href,text);
    }
    return newHTML;
}
/**
 * @param html: The block of html to be displayed in the print window.
 */
function openPrintView(content) 
{
    // specify window parameters
    printWin = window.open
    (
       "", 
       "print",
       "width=600,height=450,status,scrollbars"
       + ",resizable,screenX=20,screenY=40"
       + ",left=20,top=40"
    );
    // write content to window
    printWin.document.write('<html><head>');
    printWin.document.write('<link rel="Stylesheet" type="text/css" href="style.css">');
    printWin.document.write('</head><body>');
    printWin.document.write('<span id="printcontrols" style="float:right;">');
    printWin.document.write('<a href="javascript:window.print();">print</a>');
    printWin.document.write(' | <a href="javascript:window.close();">close</a>');
    printWin.document.write('</span>');
    printWin.document.write
    (
        printFormat(
        document.getElementById(content).innerHTML)
    );
    printWin.document.write('</body></html>');
    printWin.document.close();
    printWin.focus();
 }
</script>

You can then apply a style rule to hide just the print controls in the new window:

<style type="text/css">
@media print
{
    #printcontrols 
    {
        display:none;
    }
}
</style>

Pros:

1. Uses an inclusion rather than exclusion strategy. You can grab other elements off the page using parent.getElementById() methods and writing them into the window. This way, when new elements are added to the page, there is no need to modify the print CSS to exclude them.
2. Can be used to strike a balance between presentation control and user control. The JavaScript references just the block of html you want to print, so on a page displaying multiple articles or reports, the user can pop-up a print-view of just the section they want.
3. Can serve as a “Print Preview” function for slicker web browsers, like Google Chrome, that don’t have that feature.

Cons:

1. No permalink with this method (A permalink could be provided with JavaScript that reformats the page onload, but that’s klugey.)
2. Like the server-side solution, this must be triggered.

While this last method is my preference because I’m a JavaScript geek, each of these methods is valid. Depending on your skill set and aesthetic, any of these, or a combination of two can serve your visitors well.