Now Direction

When your client requests a print stylesheet that matches only the content area of the site, you my friend are in luck. Just follow this formula: Kick Ass, then Take Names.

We’re familiar with the ALA method of generating a print stylesheet. The basic idea (assuming you have well-structured HTML) is to add a few “noprint” classes to specific page divisions and make them disappear. Then, format what’s left to generate nicely-printed page.

From a Content Management point of view, this is essentially a print view of your page. The only problem is that the User can print from the browser at any time, so you cannot rely on the “Print this page” link for pretty CMS print templates. This is another justification for the eventual universal Print Stylesheet.

THE PRINT STYLESHEET

A year ago, the client had a nicely printed page. My tweaks were confirmed by a graphic designer with experience in print (who has – and still does – typeset books). But the client doesn’t want a page of type, designed or not. The client wants what’s on the screen in the content area. (Fig. 1)

Fig. 1. The standard template with the Header, Navigation, Content Area, Sidebar and Footer parts blocked-out. ^

Once you get a stylesheet link added to the header (ensure that the media tag is set to “print” ), it’s easy to start debugging. First, refresh your page. Next, hit Crtl +P (or Cmd+P) to bring up your OS’s print menu. Then, hit “Print Preview.” On Mac OS 10, you’ll get a PDF of the printed page in Preview app. On Windows XP I think it’s a resized screen capture.

[On a related note: IE 6 cannot have table row padding greater than zero, or else it will crash Print Preview.]

Then it’s an Alt + Tab flick back to the CSS editor. Save. Then back and forth to the browser. Refresh. Print. Preview.

DEBUGGING PRINT CSS

A previous developer took a stab at the aforementioned standard technique and got rid of the backgrounds and some of the main areas. This was a solid head start, but I ran into the same things that he did. There were still inheritance issues. And the ASP .NET FORM and extraneous DIV elements didn’t help.

I took a swing at it, and started from the outer DIVs and targeted the header, logos, sidebar, menus, and container elements, setting them all to display:none. That worked okay, but it still created positioning inheritance issues. Some DIVs still appeared to hold their shape and position contradicting what looked like obvious overrides.

To better see what was going on, you usually just put a border on all DIVs. But I also incorporated one of the techniques for adding the actual URL address in parenthesis after an underlined link term in the copy. It amounts to some decent code that will help you identify the elements in your print preview. At the end of your print stylesheet, add this print debugging CSS:

div { border:1px solid aqua; }
div:before { content:"div: " attr(id) "-start"}
div:after { content:"div: " attr(id) "-end"}


Basically, it will trace all the divisions of your page, and add the DIVs’ ID attributes to them so that you can see who’s doing what. I find it extremely helpful when fine tuning CSS selectors. (Fig. 2.)

Fig. 2. Print preview of the debugging CSS.^

KICKING ASS

After an hour of not getting the DIVs to disappear, I stopped this silly outside-in approach of stringing huge DOM selectors to try and override all the previous styles. I went for the nuclear option. I deleted the print styles and replaced them all with one line:
div { display:none }

TAKING NAMES

Then, I gave the body a black border { border:1px solid #000; } and set the margins and width on it, similar to the “artboard” in Adobe Illustrator. From there, I walked down the DOM tree of the Content Area, turning “on” each DIV, and adjusting dimensions as I went. The print debugging code (above) helped because I could see each new border turn “on” as I saved a new rule.
#someElement {display:block; margin:0. padding:0; position:relative; visibility:visible; }

For this fairly good-sized site, this approach worked very well. Nuke everything, then turn on only the parts you want. By contrast, to go and name everything you don’t want can be error-prone, time consuming, and inefficient to code!

In the end I displayed exactly what the client wanted (their content area) and it even saved them some time & money.