MikePadgett.com

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.”

Source: Wikimedia Commons

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

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.