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.

Aaron Mentle presented this point at BarCamp South Dakota last summer. Coincidentally, I was in the shower that very morning thinking the same thing.

There are basically three stylesheets that you end-up with when templating a CMS:

1. The Browser Reset – By now, you should have a comprehensive version set to some hotkeys. Between Meyer’s, YUI, and the several popular CSS scaffolds, I’ve never written one from scratch.
2. The Surround – This is the big one, where half of your CSS work is done to create a functional page layout that matches the design. This can include, but is not limited to a header, breadcrumbs, navigation, sidebar(s), tertiary navigation and a footer.
3. The Content Area – This is the other half where your users can enter content in their admin editor area. This can be straight text, a WYSIWYG editor, or even sorted views of content straight out of the CMS. Just when you think you’re done, there’s forms that have to live in the Content Area, too!

The browser has to load all of these so your h1 tag gets assigned about four times! Once from the internal browser styles, then it’s reset, then it’s spec’d for the design, then it’s declared yet again when it cascades into the content area. Graciously, modern browsers are wickedly efficient when doing this.

Which begs the question: could your site be more efficient? What if you just set the values from the start? Sorry to disappoint, but it’s basically negligible. However, there are a few things that you can do to optimize your CSS for browser DOM crawling. This is more of a philosophy about organizing your stylesheets, too.

1. Use IDs – There should only be one ID per document, so once a browser finds it, it can disregard the rest of the DOM.
2. Namespace any HTML tags with ids – #Header h1 Instead of searching the entire document for every h1 tag, the browser can focus on the #Header div to look for h1s exclusively.
3. Use only one class in a selector – Because every DOM element has the potential to have many classes, you need to limit their use to one or two specific ones.

Happy styles!