Tag Archives: CSS

Sticky footers

Not to be confused with stinky feet, sticky footers are a CSS technique whereby a page footer always appears at the bottom of the page/window, even if the content of the page isn’t tall enough to fill the window completely. (For you HTML-phobes out there, normally all of the content on a web page flows vertically one element after another, meaning that your page “footer” can potentially end up in the middle of the window, with a bunch of blank space below it, if your page content is too short. Not to be confused with Too Short.)

I have seen sites whose owners had solved this problem, but as it’s never really been an issue for me (since I never have too little content to fill a page, I guess!), I haven’t bothered to dig into the solution, until today, when I needed to for work.

The Man in Blue (also known as Australian author and self-identified “web technologist” Cameron Adams), has posted an elegant solution, which has also been floating around in various forums.

It goes something like this… season to taste:

html {
  height: 100%;
}
body {
  height: 100%;
}
#nonFooter {
  position: relative;
  min-height: 100%;
}
* html #nonFooter {
  height: 100%;
}
#footer {
  position: relative;
  margin: -7.5em auto 0 auto;
}
/* A CSS hack that only applies to IE — specifies a different height for the footer */
* html #footer {
  margin-top: -7.4em;
}

OK, winter, we get it

I knew it was probably coming, so it wasn’t a total shock. But still… I woke up this morning to this:

Ugh. It will most likely have melted by noon, I suppose. Not that that will do much to repair my severely damaged psychological state.

Even worse, I’m annoyed that the default CSS for the new WordPress gallery functionality uses float: left so when there are only two images, it doesn’t center them, but leaves a nice, perfectly-sized void where a third photo would have gone. I’ll have to fix that. Speaking of voids, my annoyance (and distraction) at snow and CSS is somewhat compensated for by the smooth “electronic breakbeat jazz” grooves of Revolution Void.

Update, 8:13 AM: Great, now it’s actually snowing more. Take that, global warming! (Yes, please check out that site, if for no other reason than to prove that just because your URL is “globalwarming.org” doesn’t mean you’re a benevolent non-profit trying to save the world.)

OK, Microsoft, you’re off the hook…

But not in the way that the Cheat is off the hook.

I fixed the IE6 CSS problem I ranted about yesterday, and it was perhaps one of the more satisfying solutions I’ve encountered where IE is concerned, because all it required was that I remove a few lines of CSS code that turned out to be unnecessary anyway.

My approach to CSS is one of building a solid page structure and then fine-tuning the details until I have exactly what I want. A side effect of this is that sometimes I leave in unnecessary definitions along the way. If they don’t alter the output in the browsers I test (Firefox always, Safari often, IE7 at least once or twice along the way), then it’s good.

But in this case I had an entire definition that was completely unnecessary. It wasn’t hurting anything in Firefox or Safari, but it was doing all sorts of crazy crap in IE6. Naturally, in such a situation, I blame Microsoft.

To be honest it’s not really (entirely) Microsoft’s fault. I have to recognize that I’m building pages to be interpreted by different rendering engines (the latter part of which is where Microsoft’s blame, to the extent it exists, resides). But there are an unlimited number of ways to write standards-compliant code (which I think I do pretty well, most of the time), not all of which lead to the same desirability of output. So if there’s a standards-complaint way to also accommodate IE’s quirks, that’s the way to go. My biggest problem is that my access to IE6 is fairly limited, and IE7, although it has its own quirks, is a lot closer to what Firefox and Safari produce.

So… there you have it. The site should now look good in every major browser currently in use (Firefox, Safari, IE7 and IE6). If not, complain below!

On a side note, Steve Ballmer sticks out his tongue a lot. (Even when you’re not deliberately looking for it.)

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.