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

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.

Comments

2 responses so far to Testing CSS for print media: we need a Print Preview for developers!

  1. Gravatar Matt says:
    August 5th, 2009 at 2:34

    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:
    August 5th, 2009 at 7:22

    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.

Why not give me your comments?

See also:

jQuery .html() returns strange results in IE after other bindings

Internet Explorer: where it belongs?

This article originally addressed jQuery 1.3.1. See below for results in jQuery 1.4 (18 January 2010) When I’m testing work done with jQuery in Internet Explorer, I’m normally a karmic cow. ...

  • Originally published: 17 Feb 2009 in Technical

RouteOne online: doing the BUSiness

The old RouteOne design

The old RouteOne website A new website for RouteOne, the leading publication in the Coach and Bus industry, is set to go live shortly. My job was to turn the old offering ...

Graphic Designers are not Web Designers

Heavy Backpack - screenshot

This item is a follow-on really from a statement I made in my previous article about User Experience 2005: how we are web designers rather than artists. J recently pointed out ...

  • Originally published: 24 Nov 2005 in Technical

Wrangling writers: information design and content policy

Carl Spitzweg's 'The Poor Poet' (1839) Photo: Mike Padgett

Notes on important themes in the close relationship between information design and content writing and editing. ...

More IE woes: the curved corner DIV

In my current efforts to adhere to div-only layouts, it was expected that I would eventually get to a sticky point. I’m not used to hacking CSS, so progress for me ...

  • Originally published: 19 Jul 2005 in Technical

Who is that guy?

Photo of Mike Padgett

Hello you. I'm Mike Padgett and I work in the technology sector as an Information Designer.

I also enjoy travel, concerts, films and walking.

I'm based in Brussels, Belgium. My current favourite Belgian beer is St Feuillien Brune.

RSS feeds