Some will find this a very dull topic, others may be enthralled. But in the end we all need to pay attention to the printers of the world — and there are many of them.

As a lead designer for a company with a very strong brand I have the opportunity to be seen by a lot of eyeballs. That comes with a price, of course. With such a large audience we have to pay attention to a lot of different types of users and user patterns. One which has always been forgotten on the web is designing for Print. More directly: designing your page so it doesn’t totally suck when printed.

I’m not going to cover a blow-by-blow here on how to do all the yummy CSSness, but I will cover a few things that I had to overcome.

First an important note: all of these behaviors are decided on by the browser manufacturer. They are not following any standards here, so check as many browser as your web logs say are important to your project.

1. CSS Stylesheet

The best pattern you can start with is attaching a stylesheet designed for use when printing only:

This can be in a new stylesheet or included in one you already deliver, or even tacked into the header of the html file. What is important is that you are defining this for “@media print”. There are a lot of media types to be aware of. And to become a true CSS-guru you really should be using a variety of these on every project.

Media Type Description
all Used for all media type devices
aural Used for speech and sound synthesizers
braille Used for braille tactile feedback devices
embossed Used for paged braille printers
handheld Used for small or handheld devices
print Used for printers
projection Used for projected presentations, like slides
screen Used for computer screens
tty Used for media using a fixed-pitch character grid, like teletypes and terminals
tv Used for television-type devices

 table from w3schools.com

I have a few simple styles defined there that attempt to hide and show things according to the media type. Note, the “onlyprint” style is defined in 2 places. We want to make sure we “hide” things marked with “onlyprint” on the screen. So we have to have that defined in our standard stylesheet as well.

2. Backgrounds

First and foremost, you have to know that all the major browser makers are trying to save you ink. It’s a nice thing for them to do, really. But as a designer if you don’t think about this your beautifully sculpted web page will simply disappear before it ever reaches the print buffer.

The Problem

Many of us use CSS to change the background color of divs to “color” a page without the extra cost of delivering images. Nice trick, but for printing it comes at a cost. Browser makers do not print background colors by default.

Wait! That doesn’t even make sense any longer.

As you can see in the image when printing the background colors were lost. Also note that the text color was not adjusted to match (this is a place where IE bettered other browsers as it adjust the “light” text to “dark” text when it removed the div backgrounds). Without ever testing a print preview on this page almost all traceability of what was printed would have been lost.

The Solution(s)

There are a few things you can do here. The first is a little CSSness.

Notice that I have chosen to apply the above to all div’s in this example. This is likely not needed for your example. Apply it wherever you feel the background is meaningful. But, of course, this is not the whole story.

At the writing of this post Chrome, Firefox, and Webkit browsers listen to the style above. But IE is different (see last item of this post for more on that).

 

3. Sprites

Okay, so you have those sweet backgrounds back. And through the magic of the internets you learned all about using sprite sheets for your images. I admit, I love them. I also develop games (as you might notice around here) and sprite sheets are invaluable. Once I heard about them for HTML I jumped all over them.

Which was unfortunate.

The Problem

Turns out sprites (which are backgrounds positioned properly on an element) are simply more backgrounds (see problem #2 above). So by default they do not print.

My beautiful buttons were lost to the ink-saving gods

Once you add the juicy CSS rule above in your stylesheet they will begin to show up. However, all is not cool there either. As you can see Chrome (as of this writing) did not size the background image properly.

Look at that awesome resampling of my buttons.

The Solution

With all these issues I had to mainly move away from all sprites or hide those elements during printing. This was a last-ditch decision. Both the printing and the load time suffered ever so slightly because of this bug.

4. Inline styling

This is a simpler concept but equally important as the others. There were several elements that needed to show up on the printed page, but not on the screen. This is easily achieved with CSS, but there is a small yet important catch. As you plan the layout of your page you should start with the load process, not the finished product.

FOUC IS NOT YOUR FRIEND

 I did not want un-styled content flashing until our external stylesheets loaded. To manage this I moved my rules as close as possible to the DOM draw step: inline.

With the above HTML you can see that I am immediately disabling any display including spacing. But I am also setting my “onlyprint” class on the element. Making this an inline style makes the affect immediate. But it also makes it much more agressive. Remember that the rule “closest” to the element wins in the cascade. This means that any stylesheet trying to redefine the display setting of this element will not take effect.

The answer to that is !important. That’s right. If you look back up at item #1 in this post you will see that I have 2 standard styles “noprint” and “onlyprint”. On those definitions you will see the !important denotation. This indicates to the browser that “this definition should take precedence in all cases”.

5. IE is “different”

Okay, that one seems pretty obvious, right? Well, it holds true even today. With IE 10 being released soon we will see IE finally get in line with many HTML 5 standards. However, printing background colors is not any kind of standard. Which is really a  shame to me. Since there are CSS rules governing the print media I wish the standards body would go as far as to outline some basic standards on how things should print.

At this time, that’s not the case, so you have to live with it. You should understand that IE will not print background colors. Microsoft feels this is a user option, not something that a website should be able to dictate. And I wouldn’t mind that decision so much except they bury the setting to allow users to enable background color printing in the user settings of the browser. At the least they should offer that as a setting on the print preview dialog.

Alas, that leaves you with only a few options. I will mention them here, but not get you close enough to a cut/paste solution as you’d like. And if you’ve read this far… YOU’D LIKE. Sorry.

The best I can offer here is that you can create new styles for your backgrounds that really need color and include images that your repeat in them. This is much harder than that as you will likely want content on the top of the color and that will then need to be embedded into another div or element.

It’s possible that the HTML5 Canvas may be of some help here. But that’s a large restructuring as well.

In the end my “solution” for IE was to add borders around these elements and allow the outline to serve as a visual break.

I told you the solutions here weren’t going to help much for IE. But, if you are seasoned at all, you knew there was going to be some part here that said “you just can’t do that in IE”.