15 Jun 09

Testing CSS for print media: we need a Print Preview for developers!

How I wish there was an easier way to test CSS intended for the printed page.

The virtues of @media print have been explained elsewhere, best of all by Eric Meyer in his seminal A List Apart article Going to Print, whose original publish date (May 2002) makes me feel a bit old!

Yet one of the most annoying aspects of developing CSS for print is testing it.

Now I know that testing print CSS doesn’t take a huge slice of our lives, but it annoys the heck out of me. So if you’re a tolerant sort of person who’s happy to rub along with naff workflows, you might find this article and indeed the fact that there’s a whole article on the subject, just a bit finicky.

Thing is, I hate testing print CSS.

Sure, simple markup and layouts only need buffing to a shine to be ready for print, but an increase in complexity or a requirement for absolute fidelity in printed material can lead to ugly scenes round my way.

Print CSS: browser testing !== Print Preview testing

Print styles in Firefox and Internet Explorer

Developers tend temporarily to substitute their screen CSS for their print CSS, run it in the ordinary browser environment, et voilà. Rinse and repeat.

Yet the actual conversion to the printed page can sometimes lead to unexpected results, as can be seen in the image: different browsers, different Print Preview results – even though in the browser there was nothing obviously objectionable.

Print Preview !== a tool for development

Finding fiddly print CSS issues would be a lot easier if testing tweaks was a smoother process. Every change cycle equates to:

  1. Refresh the page
  2. Invoke Print Preview
  3. Review the change
  4. Close Print Preview

Testing print CSS as opposed screen CSS appends two additional steps 2 and 4 – invoke Print Preview (Alt + F + V in Windows for both IE and Firefox) and close Print Preview (correspondingly Alt + F4) . Those two simple steps make the business very laborious, even if you can remember those shortcuts.

Slight workflow improvement: an IE-only trick

A dirty little script in IE only takes care of the task of invoking Print Preview, which slightly shortens the workflow. Yes, it’s IE only, but given that it’s usually IE giving me print CSS grief, every little helps:

<script type="text/javascript">
function printpr()
{
var OLECMDID = 7;
var PROMPT = 1;
var WebBrowser = '<OBJECT ID="WebBrowser1" WIDTH=0 HEIGHT=0 CLASSID="CLSID:8856F961-340A-11D0-A96B-00C04FD705A2"></OBJECT>';
document.body.insertAdjacentHTML('beforeEnd', WebBrowser);
WebBrowser1.ExecWB(OLECMDID, PROMPT);
WebBrowser1.outerHTML = "";
}
printpr();
</script>

This script automatically invokes IE’s Print Preview. Dump it just before the </body> and save yourself a shortcut! You could also call printpr() from anywhere else, of course. And here’s the source of the original code snippet, which also shows a few other unrelated options such as Save As.

Why can’t we refresh the Print Preview?

All of which finally begs the question, why can’t we simply refresh the Print Preview with an F5 shortcut, just like we have in the browser itself?

Probably because I’m the only person in the world who gets genuinely annoyed by testing print CSS in Print Preview. More fool me, I guess.

Tags:

15 comments

  1. Gravatar Matt says:

    No, you’re not the only one. I’m knee-deep in the middle of a project with this exact same frustration. Everything you say is true, and not a browser one (that I’ve run across, err, a browser that *really matters*) has any feature set that eases the pain we feel.

    The Web Developer extension for Firefox has an attempt at facilitating print media CSS development (CSS > Display CSS be Media Type…), but I haven’t gotten it to work for me. I don’t know if it’s my CSS, or the extension itself… doesn’t seem to work.

  2. Gravatar Mike Padgett says:

    Quite right, Matt, and it’s good to hear it’s not just me!

    Chris Pederick’s Web Developer Toolbar does indeed have that facility, which is useful (and it works for me).

    However, maybe like me you’ve also found that there are often problems that you only discover when you actually do Print Preview or print the page, such as the one you can see in the picture which can occur with floated elements.

  3. Gravatar Andrea says:

    True, the first few times you don’t mind closing, refreshing, and reopening (not to mention scrolling back to the point your checking) but after a while it becomes so annoying you find yourself reconsidering the whole project! Thanks for the tips on the extensions, but they are of no help because the print preview can be completely different from the browser view w/print stylesheet, especially if you use a multi-column layout since this restarts on every printed page, but never does in a single web page. Margins can also be an issue, and I guess a number of other things… So, I’m wondering if a FF extension could add a Refresh button or shortcut to the preview environment…?

  4. Gravatar Ben says:

    Yup.

    Same deal over here – working on an event calendar that prints to a ‘fridge calendar.’

    Not tough, but very, very, tedious going back and forth….

  5. Yeah, I’m missing that reload function in print preview too! I just submitted this as an “Idea for Firefox” (looks like they discontinued the Bugzilla system for submitting requests for enhancements – so people cannot vote for anything anymore :-(

  6. Gravatar Shirley says:

    Yes, print preview is a chore. I usually just set up a separate print stylesheet on a development site and tweak it that way and preview across browsers. It would be great to have a comprehensive tool to simplify testing.

  7. Gravatar Jason says:

    I just want to keep this thread alive. HATE print css!!! I wish there was a user-agent we could invoke and just see it in the browser, then use the inspector to figure out what was going on. And I hope someone reads this that can make that add on for FF, Saf, Chr & IE and does it!

  8. Gravatar ptamaro says:

    Great post. I’ve always felt print specific CSS was worth the effort, but it’s definitely a chore, at best! Especially when you go beyond minor cosmetic tweaks, print-specific content, and just hiding stuff that doesn’t make sense on a printed page — and try to delve into tricky layout changes to the content…

  9. Gravatar Ytio Khu says:

    Great post. I hate print CSS testing too. Its just such a pain in the …

  10. Gravatar yunsheng says:

    I have a different issue:
    I have two media in css: screen and print. I have to refresh the page in order to do Print Preview because the Preview only works after refresh. If you close the Preview and launch it again without refreshing the page, the Preview will always use the Styles for screen.
    Any helps will be greatly appreciated.

    • Gravatar Mike Padgett says:

      Yes, that’s exactly the problem: the workflow is inconvenient. The compromise I use is to temporarily hide the screen styles (by commenting out the link element, for example) and simply work with the print styles on the screen. Not an ideal solution but you can do a lot of the heavy work before using Print Preview just to check the final result.

  11. Gravatar yunsheng says:

    Thanks a lot for the help and quick response!

  12. Gravatar Andrew Heald says:

    I’m using wkhtmltopdf with the –print-media-type switch to generate PDF versions of all my pages on a static site I’m building with Jekyll. In some cases the PDF is more important than the HTML here. While I’m tweaking the print CSS I bring up the PDF URLs in Chrome which gives me a single click refresh on any changes. That’s the best workflow I’ve managed so far.

Speak your brains

Your email address will not be published. Required fields are marked *

CAPTCHA Image

(required)

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>