When you inspect an IMG (image) tag that is wrapped in an A (anchor) tag, you will see that the A tag is not actually expanding to cover the image. (Fig 1.) The A tag is represented as a horizontal bar that extends several pixels above and below the baseline of your image.

At first this is surprising, but once you verify that it still functions as expected, you scratch your head and move on to more pressing matters. And pray that the Pixel Bitch doesn’t notice.

Figure 1. Inspecting the A tag of the A IMG combo (with Firebug in Firefox). See how it’s flattened at the base of the image? ^

I played with the CSS display property of the A tag until I got it to cover the image. First try: div.ad a { display:block; }

Okay, so now the “A” tag now displaces the correct height of the image. And there is the added benefit of losing that extra 5px or so pixels of vertical margin underneath of the image. (Fig. 2.) It’s odd because that amount of space has a certain minimum height that’s based on the font and line-height since the default is display:inline.

Figure 2. Fixed on inspection and behaving properly!^

The net effect is about a five pixel decrease in padding under the image. And if you still have :focus on, you’ll see that it snugly wraps the image border instead of just appearing at the base.

The permanent fix to this minor issue? Set display block on all A tags that have child IMG tags.

a>img { display:block; }


Veddy nice.

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.

1. Open a new tab and go to about:config
2. Type in “network.http.pipelining“
3. Click the booleans to switch their values to true, and double the integer to “8″ instead of “4.”
4. Close the tab.

Happy surfing!

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!

A section later, we’re at the obituaries. A particular one surfaces at the top center: Laurence Kim Peek. “Ah!” says Grandpa tapping the write-up. “That’s Rainman. Kim Peek. He was the real Rainman; the one that Dustin Hoffman played? That was him.” I think, “Wow? He was still around?” I have the same sense of shock when I heard Oliver Saks alive and well on the NYC Radiolab podcast a few months ago.

Grandpa continues, “I met him down at the library about 20 years ago.

“He just walks up to me, and says ‘Hi, I’m Kim.’

I’m like, ‘Oh? Hello. I’m Howie.’

‘Howie what?’, Kim replies.

‘Howard Lemcke.’

‘How come you say you’re Howie if you’re Howard Lemcke?’

‘Well, it’s a nickname.’

‘Oh.’ And there’s not so much as a pause when he comes back with, ‘You’re not in the phone book.’

‘Well, you’re right! I’m not.’ And we continue with that whole bit about protecting the privacy of public officials. I tell him the alias.

‘Mmmm… Eighteen-oh-three wasatch boulevard. Eight-three-one-two-three. Eight-oh-one four-two-two thirteen-sixteen.’ And he just rattles it off.

I said, ‘That’s right again!’ And he smiled and left to introduce himself to someone else. One of the oddest interactions I had a the time.”

If you have resort to all th