A List Apart

Menu
Issue № 203

ALA’s New Print Styles

by Published in Browsers, CSS, Layout & Grids38 Comments

As things began to come together for the launch of ALA 4.0, we realized that the print styles weren’t up to where they needed to be.  Thanks to some maddening browser behaviors, articles were printing out partially, or with severely mangled layout.  It wasn’t just one browser, either.  This was something that would need time and energy to address, and all our time and energy was going into making sure the launch went smoothly.

But could we launch without print styles?  After some discussion, we decided that the answer was yes.  Given the low awareness of print styles and disinclination of most people to print out web pages, we figured that we could wait until after the launch to fix up and deploy the print styles, with little or no impact or notice.

Okay, so we were wrong.  How times change!

After all, it used to be that the biggest question about print styles was whether or not they were really useful, let alone used by anyone of note.  Sure, here at ALA we’ve been using print styles for a long time, and my previous ALA article “Going To Print” got a decent amount of attention.  We’ll grant you all that.  Even so, we were surprised at how many people asked after the print styles.  Some of you came awfully close to demanding them.  Times change indeed.

Last week, we got the print styles up and running for our articles.  Herein, I’d like to take a quick look at how the print styles were arranged, and reveal how one small omission caused a raft of problems in multiple browsers.

Important unstyling

The first step was the easiest: “switch off” the presentation of elements that were useless or confusing in print.  For example, the sidebar is next to useless in print.  So is the navigation bar across the top of the page.  Leaving them in place for print means wasting paper, ink, and the reader’s time.  Similarly, there was no real need for the discussion-related pieces of the page.  And finally, I decided to save a little more ink and get rid of the ALA logo in the top left corner of the document.

All this was easily accomplished with a single rule:

#masthead, #navbar, #sidebar,
#metastuff b, #metastuff .discuss, div.discuss {
  display: none !important;
}

Why make the declaration !important?  Because it’s, well, important that those elements not appear in print.  I’ve been known to say that leaving !important in a publicly deployed style sheet is usually a sign of laziness, but I’d like to offer a modification to that maxim.  I’ve come to believe that’s true within a given medium; that is, if you’re leaving in !important directives on screen-medium styles to override other screen-medium styles, then odds are you’re being lazy.  (Yes, there are exceptions, but they are rare.)

When you’re mixing media, however, the use of !important becomes more defensible.  Take the ALA styles: all of the styles used in a web browser come through a single link element, and those styles are applied in all media.  On articles, for example, we have this:

<link rel="stylesheet" href="/css/article.css" 
type="text/css" media="all" />

This was done so that the overall design look of ALA would carry into media such as print.  The alternative would be to restrict these styles to the screen medium, and then have to recreate some or all of them for print.  The approach I took was a lot more efficient, in terms of style sheet authoring.

Now, was it truly necessary to use !important in the print styles?  No.  I could have raised the specificity of each selector in the rule and been fairly sure that they would have had the intended effect.  The rule would then have looked something like this:

html #masthead, html #navbar, html #sidebar,
html #metastuff b, html #metastuff .discuss, html div.discuss {
  display: none;
}

Better?  No.  Not necessarily worse, either.  Just different—but, to my eye, less efficient, not to mention less readable.  So I stuck with !important.

(And yes, the user can set up a user style sheet with his own !important directives to make those elements reappear. The important question is, how many people will bother to do so, and why should it bother me if they do?)

Knocking columns out

Another place I used !important was the very next rule of the style sheet:

body, #main, #content, .column, #articletext, #footer {
  width: auto !important;
  margin: 0 !important;
  padding: 0 !important;
}

The goal here was to take the pieces of the layout that still persisted and make them as wide as the page’s printable area.  In the screen layout, after all, the content column is set to be a specific width.  That width might be more narrow, or wider, than a page’s printable area.

To make sure that happened, I zeroed out the margins and padding of the elements in question.  Then I set all the widths to auto.  Why not 100%?  Because over the years, I’ve grown wary of setting an element’s width to 100%.  Because of the way the CSS layout algorithm is written, it always feels to me like I’m gambling a little bit with width: 100%;.  In this case, if a margin or padding ever did somehow creep its way back in, then an element could easily become wider than the print area.  By explicitly declaring auto in this case, I’m saying “take up as much room as there is available without pushing the element outside the print area, even if there are somehow margins or padding.”

Given the styles we have here, the end result of using 100% or auto is the same.  auto is slightly more future-proof, however, so I went with it.

A remade issue bug

When it came to the top of the first page, I faced some interesting choices.  The issue number, for example, is created by laying styled XHTML text on top of a background image.  As many of you know, browsers by default will not print backgrounds, and there’s no way for an author to turn them on.

In the end, the solution was to restyle the issue number and its publication date, and put them at the “top corners” of the document.  That sounds simple, but it led to some styles that appear, at first glance, to be anything but simple.

html body #ish {position: static; width: auto; height: auto;
  margin: 1em 0 0; padding: 0; border-top: none;
  font-size: 0.9em; text-align: right;
  background: none;}
html body #ish a:link, html body #ish a:visited, html body #ish a em {
  position: static; display: inline;
  font-size: 1em; font-weight: normal; 
  width: auto; height: auto;
  margin: 0; padding: 0;
  background: none; color: #555;}

What’s all that?  A lot of it is simply undoing what the all-media styles are doing.  Let’s take a look at the #ish styles from base.css.

#ish {position: relative; z-index: 10; 
  border-top: 1px solid #666;
  font: bold 10px Arial, sans-serif; letter-spacing: 1px;}
#ish a:link, #ish a:visited {position: absolute; 
  top: -33px; left: 150px;
  width: 65px; height: 52px; padding-top: 13px; 
  text-align: center;
  background: url(/pix/ishbug.gif) top left no-repeat;
  color: #FFF;}
#ish a:hover {background-position: bottom right;}
#ish a em {display: block; margin-top: -0.2em;
  font: 2.33em Georgia, Times, serif; letter-spacing: 0;}

There’s a whole lot of positioning and sizing that had to be overcome in order to create a simple, unobtrusive issue number.  Here are the print styles again, except this time I’ve emphasized the parts that exist mostly or wholly to undo the all-media styles.

html body #ish {position: static; width: auto;
  height: auto;
  margin: 1em 0 0; padding: 0; border-top: none;
  font-size: 0.9em; text-align: right;
  background: none;}
html body #ish a:link, html body #ish a:visited, html body #ish a em {
  position: static; display: inline;
  font-size: 1em; font-weight: normal; 
  width: auto; height: auto;
  margin: 0; padding: 0;
  background: none; color: #555;}

Beyond those, the styles are pretty simple: right-align the issue number, make its font size a little bit smaller than its parent’s, and lighten up the text color.  That’s more or less it.

Reworking the date

After that, the styling of the issue’s publication date is almost trivial.  As the issue number was placed to the right, the date goes to the left.  In order to place them “on the same line,” visually speaking, I simply pulled the issue date upwards 1.5 ems.  A two-em bottom margin made sure that the content after the issue date was pushed downward far enough, and we were all set.

html body #content .ishinfo 
  {padding: 0 0 0.5em; margin: -1.5em 0 2em; 
   text-align: left;
   background: none; position: relative;}

The only little oddity here is position: relative.  I included that because IE/Win has a tendency to make elements disappear if you pull them upward like this.  The cure is to position them, which I suspect triggers the hasLayout flag.  I don’t pretend to understand all the nuances of hasLayout, but recent information from Microsoft and third-party sources has shed quite a bit of light on the subject—it would appear that many of the layout problems that bedevil us in IE/Win are the result of an element not having hasLayout.

Assorted cleanup

Having gotten the issue number and date in line, all that remained was to clean up various bits here and there.  For example, the “metastuff” line at the beginning of each article needed to lose its background, and the “Learn More” section’s border had to be adjusted a bit since it was no longer followed by the “Discuss” box.

html body #metastuff {background: none;}
html body #learnmore {border-top: 0; 
   border-bottom: 1px dashed #999;}

Similarly, the footer needed a rework.  The tagline “From pixels to prose, coding to content” was actually done as a background image in order to preserve its typography, so we knew it wasn’t going to print for nearly everyone.  To make sure, I dropped it and shifted the footer’s paragraph so it filled the entire with of the footer and didn’t have a left border.  At that point, centering the text seemed like a good move too.

html body #footer {background: none;}
html body #footer p {border-left: none; 
   margin-left: 0; text-align: center;}

Finally, I added some styles to auto-insert the URLs of links that appeared in the article text, the author’s biographical note, and the footer itself.

#articletext a[href]:after,
#authorbio a[href]:after,
#footer a[href]:after {
   content: " (" attr(href) ") ";
   font-size: 90%;}#articletext a[href^="/"]:after,
#authorbio a[href^="/"]:after,
#footer a[href^="/"]:after {
   content: " (http://alistapart.com" attr(href) ") ";}
 

Rather than try to explain all this here, allow me to refer you to my article “Going To Print,” which has a detailed exploration.

The key to clarity

All those things are well and good, and they worked quite nicely in short articles.  If an article ever got longer than three pages, though, the margins on pages four and later would go berserk in Firefox.  Usually the content would only be about a third the width of the page’s print area, and the third it occupied would change from page to page.  To add to my frustration, IE/Win wasn’t printing the footer at all in many cases.

With a good deal of experimentation, I was able to get the footer to reappear in IE/Win using some borders and positioning, but the Firefox problem just wouldn’t go away.  Frustrated, I put out a call on my web site, and Dan Wilkinson stepped up with the answer.  One simple addition solved both problems:

body, #main, #content, .column, #articletext, #footer {
  float: none !important;
  width: auto !important;
  margin: 0 !important;
  padding: 0 !important;
}

So simple, yet so powerful.  I’d neglected to un-float the content that remained, and that was throwing all kinds of monkey wrenches into the gears.  Once I’d added that declaration, I was able to remove my IE/Win hacks for the footer, and Firefox stopped mangling the layout on pages four and later.

So let my mistake be a lesson to you all: in print, always un-float large elements, especially long elements containing things like article text.  As a general rule, when a float runs to multiple pages, you’re just asking for trouble.  Ignore this at your own peril.

(And don’t think Safari was free of printing bugs either.  The only reason it didn’t come up in this article is that its bugs only occurred in print styles that were dropped as we refined the print design.  In other words, it got lucky.)

Collation

So is this the last word on ALA print styles?  Not entirely.  In the first place, we may tweak the print styles over time.  In the second, these print styles are only used on articles, which are the pages that are most likely to be printed.  Other pages, like the home page or other top-level pages, do not currently have print styles.

Will they?  That’s an interesting question… and one to be considered some other day.  For now, I hope the print styles for ALA 4.0 meet their design goals as well as make the process of printing an article more pleasant.  Thanks to everyone who gave us feedback on the lack of print styles—it vividly demonstrated that things have really changed in the last few years, and that print styling is an important and valuable piece of web design.

38 Reader Comments

Load Comments