The incredible ever-changing page background

Here’s more stuff that web designers might find interesting and everyone else will find either irrelevant or won’t even notice.

I kind of liked the abstract image I had as the background of the pages in this new site design (which, if you’re interested, can still be found on my IE6 users’ “welcome” page), but I was never completely satisfied with how it was just shoved into the upper left corner of the window. So I took a horizontal cross-section from a very colorful portion of that design, stretched it out into blurry vertical stripes, and made it the new background.

But, you may notice, there’s a bit more to the background than that. Once again it’s the magic of PNG alpha channel transparency at work.

The background of this page is actually the product of 3 separate images (a JPEG at the “back” and two transparent PNGs over it) overlaid on top of each other. In the bottom layer is the aforementioned blurry multi-colored vertical stripe image (JPEG). It’s 1600 pixels wide by 20 pixels high, tiled.

Next above that is my “Close to the Edge” image, a gradient from the teal of my color palette (at the bottom) to transparent (at the top). For a while I toyed with simply using this as a teal-to-black gradient, and I have to say it looked quite nice, but there’s not enough else going on visually with the design of the page, so a solid black band at the top of the page came off a bit boring. So, the gradient as an overlay on the stripes. This image is 50 pixels wide by 600 pixels high, and it’s fixed to the bottom of the window and tiled horizontally.

Above that is the (probably overused) “NTSC scanline effect” image, which produces the horizontal stripes. Unnecessary and as I said, probably overused, but it’s still kind of cool looking. Or would have been in 1998 at least. Call me old fashioned, if you think 1998 is old. (OK, in the web world, it’s ancient history.) This is a 20×20 image, also tiled.

So, how does this all fit together? Well, the way I do it is by applying the JPEG to the <body> tag, which is immediately followed by a pair of nested <div> tags that fill the window and exist for the sole purpose of overlaying the other background layers. Then inside of that, the rest of the page’s HTML appears as normally.

Looking at it precisely, the CSS file contains the following:

body {
  background: #000 url(“images/body_bg_stripes.jpg”) top left repeat fixed;
  margin: 0;
  padding: 0;
}
#body_overlay {
  background: url(“images/body_overlay_bg_ctte.png”) bottom left repeat-x fixed;
  height: 100%;
  margin: 0;
  padding: 0;
  width: 100%;
}
#body_overlay_2 {
  background: url(“images/scanlines_25_black.png”) top left repeat fixed;
  height: 100%;
  margin: 0;
  padding: 0;
  width: 100%;
}

And the HTML for the pages follows this basic structure (with lots of stuff cut out in this example, of course):

<html>
…HEAD TAGS HERE…
<body>
<div id=”body_overlay”>
<div id=”body_overlay_2″>
…PAGE BODY HERE…
</div>
</div>
</body>
</html>

What’s really cool about this is that it results in a background pattern that, as a single image, would need to be at least 1600 pixels by 600 pixels (in other words, very large in both dimensions and file size), and even then it would not be able to achieve exactly what you see here because the gradient is fixed against the bottom of the window. In fact there’s absolutely no way to produce the background of this page without transparent PNGs. The 1600×600 image would easily be a few hundred kilobytes at a fairly low-quality compression level — far too big to justify, especially since it would still end up looking like crap. But as it is, the three images are 6857, 135, and 714 bytes respectively — less than 8 kilobytes combined. Sweet! (OK, it’s pathetic that I think something like this is “sweet,” but there it is.)

Thanks, Bill… this is just how I wanted to spend my Saturday

Bill, I really don’t have time for this.

Internet Explorer 6 is incapable of properly rendering CSS applied to a <div> tag when the only child element in the <div> is a table. It sticks arbitrary margins in the document below the table. Here’s an example from a site I’m working on (colors removed to [sort of] protect anonymity). This is how it should look, as rendered by Safari:

Safari screenshot

The concern is the content in the dark title bar. The bar itself is a <div> and the two buttons plus the month/year text is contained in a table. Here’s how it looks in Internet Explorer 6 (note the gap below the header bar):

Internet Explorer screenshot 1

OK. So let’s see, maybe there’s a semi-logical CSS workaround. I already have margin: 0 defined for the class the <div> uses. So I added it to any tables contained within that class as well. No luck. Then I did something really off the wall and added a display: inline property for tables contained in that class. It still didn’t work. So then, appropos of nothing, I added a &nbsp; just so there would be something in the <div> besides the table. And here’s the kicker… I actually added it before the table (retaining the display: inline property of the table:

Internet Explorer screenshot 2

Once again, it’s good that the windows in my office don’t open, or there would be one less PC in this building right now.

Of course the &nbsp; solution is not satisfactory to me. The search goes on. Because, you know Bill, I really have nothing better to do when I’m working on a Saturday morning.

At this point another alternative occurs to me: it’s possible to use the CSS float property to position the buttons and eliminate the table altogether. That fixes the problem in Internet Explorer, but…

Steve, I’ve got a few words for you as well! Look what happens in Safari when I remove the table in the header:

Safari Screenshot 2

Sure, that makes perfect sense. Especially since I have a width="100%" attribute right there in the calendar table. Oh, and did I mention that the width of the panel body is explicitly defined in pixels in the CSS? How is it, how can it be possible, that removing a table from a separate (albeit adjacent) <div> could affect the width of this table?

Now where’s my glass cutter? I think there are one too many PCs and one too many Macs in this office.

After a bit more head scratching, I’ve discovered that the cause of the Safari issue is that I neglected to remove the aforementioned display: inline property I added to my CSS in the midst of the numerous futile experiments I undertook to resolve the initial IE problem. Steve, you’re off the hook.

So, in the end, it turns out that the solution to my problem is to abandon the old-school table-based method of layout and go strictly CSS. I’m sure that’s precisely what Bill wants me to do.