Horizontal Lifestyle

Right. Let’s see if I can get this to work right. Fist you’ll need to load up a copy of IE for yourself and visit this page (if you’re not already using it).

Horizontal menus. You’ve seen them in Tank! but they weren’t quite right. So as part of this dropmenu system I’m working on, I’m including support for horizontal menus (to some extent anyways. can’t see why you’d want horizontal menus below the top level).

Compatible menus at that.

This led me on quite a journey these past two days.

First thing to realize is that those horizontal menu items have to float. They have to. Otherwise you can’t pull off a dropdown menu properly across all (or as many as possible) platforms. (Although I suppose display:table-cell might help with that a bit…) But anyways, if I’m floating, I’ll have to clear things at some point. Otherwise content that should appear below the menu will appear either on top of it or to the side of it.

Basic Markup

Here’s what the basic markup looks like:

  ><li><a href="">Menu Item 1</a></li
  ><li><a href="">Menu Item 1</a></li
  ><li><a href="">Menu Item 1</a></li
  ><li class="clear"></li

A bit funny with how the closing tags are. PUrpose is to remove all whitespace between LI elements. Otherwise IE puts whitespace between the elements on screen. That may be desirable for you, but it isn’t for me.

The last LI is a clearing element. The idea here is that all the LI elements float left and the last one clears it all out. This keeps everything neatly contained witin the UL element and requires no wrapping DIV element.

A Cute Idea

Let me start with something I tried late in my experiments. An idea that seems quite cute and I think has some merit if given the right circumstances. I was having problems getting the clearing element to work properly in all browsers. And then I set the width on the UL element to 100% to trigger IE/Win’s hasLayout property. This had a curious side-effect in other browsers. Because the UL element was now 100% the width of the browser, there was no space on either side where text could wrap around (as is the normal procedure for a floating element that is around text). So the text dropped down below the horizontal list.

Now I would have thought that the margin on the P element that immediately followed the list was responsible for that. But even if that were the case, the text should still have started to the right of the right-most menu item. But for some reason it didn’t, even in FireFox, Safari and Opera.

So it may be there’s a case to contain all your floating elements within a block element and set its width to 100% you’ll find things forced down.

I don’t know. I didn’t investigate this completely because I quickly found that it created a horizontal scrollbar in IE/Mac and that was something I didn’t want to deal with. So I abandoned it.

The Art of Clearing

So, you see my HTML up above, yes? And you see that LI element with the class property set to clear. That is a clearing element. It has one purpose, to force itself below all previous floating elements. That way anything following the clearing element will also be below all previously floating elements.

But it’s ugly, from a purist’s standpoint. It’s redundant markup. It provides no meaning and serves no informational purpose.

So for the last few years people have been trying to come up with new and exciting ways to clear without redundant markup.

One of them is quite simple, fairly compatbile, and a joy for CSS developers. That is overflow:auto;. You set that rule to a block element containing floating elements and it’ll trigger the containing block element to size itself to contain it’s floating children. It’s very simple and very nice, especially when compared to the alternative.

But there is a problem with using this in my particular case. I’m creating dropdown menus. Elements are absolutely positioned and hidden, then set to appear when a mouse hovers over a given element. Because it’s absolutely positioned it’s removed from the flow of the document. This means it’s parent element has no clue nor any care how big it is or where it is located on screen. So when I apply overflow: auto; to my UL element … it works! That is until you mouse over an element that has a dropdown menu attached to it. Then the fun begins. You get scrollbars! Scrollbars for your UL element. Those dropdownmenus? They’re there.. but you can’t really see them unless you move the scroll bars. But if you move the scrollbars you take your mouse off the element containing the dropdown and so it disappears.

Not very usable.

Although it is a very fun way to annoy people.

So that’s out.

Tried and Trued

So that clearing element then. .clear { float:none; clear:left; } should do the trick and we’re on our way, right.

No. If it were, I’d have published the menu system by now and I wouldn’t be bothering you with this long and rather dull (unless you’re a CSS junkie… I’m sorry)

Here’s the thing. Netscape 7 and early editions of FireFox had this bug where they wouldn’t recognize an element that had no content. So an empty LI like in the example way up top wouldn’t clear. The way I get around this is by applying 1px of padding to the bottom of the element. Now Netscape 7 comes ’round and all is well. Throw in a -1px top margin to compensate for the 1px of space you’ve added to the layout with the padding and nobody is the wiser about our Netscape 7 clear hack.

That is.. unless you want to apply a border or in any other way utilize the parent UL element for visual styling. For example a border. Something like what you see just beneath the masthead in skidoo. That was done using a DIV containing the UL element, so all this 1px nonsense wouldn’t really matter.

With this 1px bit you’re adding 1px worth of space below your menu items. So the border on the bottom of the UL element is going to show to your users a 1px gap between it and the menu items.

And try as I might, use every trick in the book, I can’t hide that nasty little 1px reminder of my ugly, coarse Netscape 7 hack.

Getting Stingy With HTML

Oh sure, wrap it in a DIV, solve all our problems. But I’d rather not. The name of the game, folks, is thin markup. Don’t do more than is absolutely necessary. One of the nice, shiny promises that was touted when CSS was coming into mainstream was that webpages would no longer suffer from messy markup. All the redundant nonsense we adopted during the table-hazed 90s would be gone. A window in a smoky house opened by our friend, Mr. CSS.

(Sorry. Practicing for that theoretical book and all.)

But that was all rubbish.

With IE 5 and Nescape 6 we started going DIV crazy. Why wrap it in 1 DIV when you can wrap it in 4 and put a round corner image in the background of each?!

Welcome the new style, same as the old style.

I’m as much guilty as the next man or woman. Still am, really. Hard habit to kick.

But I’m trying. And with all future work I’d like to be a bit more tight and thin with my markup. So just wrapping this up in a DIV just won’t do. I’ve got a perfectly good block element in that UL element. I don’t need a DIV. I just need to figure out how to use it.

And so…

Here’s the result.

I’m having PIE.

The :after pseudoclass has proven to be very reliable in all modern browsers (save IE). And where IE fails I can easily compensate by triggering the UL element to have layout.

For horizontal menus I can do it many ways, be it floating the UL itself (in which case I will need a clearing element, thus redundant markup) or I set the width to 100%. But IE/Mac hates 100% width! Yep, so I use a backslash hack to apply display: inline-block and that gets IE/Mac all warm and fuzzy.

Vertical menus already have a set width (be it static like 6ems or dynamic like 100%, so I don’t really need to worry here) so they already have hasLayout triggered.

So then, how are those menus coming?

Pretty well. I think I’m close. I’ve got them working in every major platform. I’ve even got IE/Mac 5.0 working. I think most of the big issues are just about ironed out. It’s the little things now that I’m on.

For example, it seems that you need to list your classes (if you assign multiple classes to one element) in order of precedence. Otherwise IE/Mac gets a bit confused.

Also I still have some minor rendering bug in IE. It draws the borders on the UL element of the dropdown menus when the menu shouldn’t be on screen at all. It only does this after I’ve viewed that menu at least once and will go away if that menu isn’t showing before I leave focus of the parent menu. It’s quite odd and could be resolved by simply not drawing borders on the parent UL at all. But then I have to use negative margins on the LI elements to overlap borders and things can get a bit muddy there… well you start to see what I mean. The little details.

I also want to add some additional functionality that lets you set where and how menus pop and drop based on the class you assign. So a right aligned horizontal menu might have dropdown menus that drop to the left, not the right, of the menu item; like what you see in Tank!.

But things look good.

I wanted to include a bit about a really odd behavior in IE I found but I’ll save that for a later post.

IE7 CSS Fixes Not All Bad

In case you weren’t aware of it already, in IE 7 the * html hack to target CSS to only IE browsers no longer works. This means any rules assigned to a selector that begins with * html will not be applied by IE7.

This is going to annoy a lot of people (such as myself) who rely on these hacks.

However I found a positive experience that comes from this change I thought I’d share.

I’m working on a new CSS-based dropdown menu system (as you know by now). And to get IE6 and earlier working with this system I had to employ the suckerfish method. This is because IE6 and earlier do not support the :hover pseudoclass. Well IE7 does support the :hover pseudoclass and running the suckerfish script under IE7 starts to make things goofy. So as a result, I had to update the script to not execute under IE7 and later.

But here’s the thing.

All the CSS applied to sfhover class is defined using the * html hack. This means, in actuality, I don’t have to go and modify the suckerfish code at all. I can let it continue to execute under IE7 and nothing bad happens. The only drawback is that you add needless overhead to processes the mouseover and mouseout events in IE7.

Now some of you might start to think “ah hah! maybe we can use the sfhover class for something else in IE7. since we’re running it anyway for IE6.” But no, you’d be wrong.


Because the goal is to get as far away from javascript as possible. We simply have no choice with IE6 and earlier. We have to work around the browser’s limitations.

The potential is there that if a bug does crop up in the final release of IE7 that requires us to utilize the opportunity, so be it. But it isn’t something we should bother taking advantage of unless absolutely necessary. Otherwise we’re just locking ourselves into javascript for the foreseeable future.

IE7 Hack?

While working on the new dropdown menu system I’ve come across something interesting.

I need to float LI elements but doing so triggers rendering bugs in Opera. So I set about finding a CSS hack to hide CSS from IE7. Of course IE7 has a lot of its parsing bugs fixed.

But then I found this one:

ul.menu[class] li

And here’s the thing. In previous versions of IE it would ignore the selector completely. In IE7 it appears to ignore everything after [class] meaning the CSS is applied to ul.menu and not ul.menu li.

Of course IE7 is still beta and this parsing bug might be fixed sooner than later. Thing is.. this hack actually works well for what I’m doing (unsetting the float property which isn’t set to begin with on the ul.menu element, meaning unsetting it with float: none; doesn’t do anything for IE.

Dropdowns And Floats

But first, what if I put together a forums system for Ruthsarian-related stuffs? It’s something that’s been on the back burner for a while but I got an e-mail suggesting it and that got me thinking a bit more about it. Any interest there?

I intend to get the latest copy of WordPress installed on this server and give it another go. If all goes well, I’ll probalby move to that platform and ditch MT.



It looks like the secret to CSS-based dropdown menus is to float everything. There are a lot of rendering bugs in IE that only go away when I start to float things. Rendering bugs that have existed since IE 5.0 are still there in IE 7. IE 7, however, now implements the :hover pseudoclass, meaning there’s a light at the end of the tunnel. There will be a day when JavaScript will not be needed to create dropdown menus that can be used by the majority of the web user base.

But IE7 still has problems. There are new bugs with the old dropdown system I used (as seen in Tank!). IE7 doesn’t like it at all. This is why it’s taking so long to get a new system put together. I’m trying to get something that works with IE7 and previous versions of IE. Opera and FireFox and Safari have no problems with the basic stuff I’ve done in the past. It’s really just IE that’s causing problems. Problems that, it seems, can be solved by using floats.


Here’s the deal. All the lists that pop-up are absolutely positioned. This means I don’t really have to bother with any sort of clearing element at the end of the item list that pops up. This is nice. It means I don’t have to worry about getting into the business of clearing.

What’s the problem with clearing?

Well, the purists believe that web pages should not contain extra markup that provides no meaning to the document. So an empty DIV being used to clear things out is considered bad form. Still, I use this method quite a lot and it appears to be the solution recommended by the w3.

W3 be damned, the purists want to be rid of that extra markup. I tend to agree too, even if I don’t practice what I preach. As a result, there have been severalh different methods developed to clear floats without the use of extra markup.

But those methods are either very specific to the application (for example, the overflow:auto clips the menus that pop to show only that bit which appears in the root menu.. ick) or are very hacky and will break in IE7 anyways (such as the P.I.E. method).

But guess what? The tried and true W3 supported method still works. Which is why, for now, this is the way I think all web developers will want to go. It’s the most compatible and the least likely to break in future/obscure browser platforms.

Now you can be clever and do this without extra markup. If you have an element that will follow your menu, an element you know will always be there, you can apply a clear:both; to that element. But this really isn’t possible in something like a skidoo layout where a clear is used to get the #outerColumnContainer element to hold all 3 columns (thus allowing for the borders on that element to carry the full height of the page and minic side-colum background colors). In that instance an empty, clearing element must be put to use. But the overflow:auto; clearing hack might apply there (I haven’t tried it yet, and won’t use it on any existing layouts, but only future layouts where applicable).

The point I want to make to you is that you shouldn’t be afraid to use an empty element to clear things out. It requires no hacks, is w3 approved, and is the most compatible solution out there.

In a world where us web developers have to balance compatibility with proper page design, this is probably the best solution.

So You’ve Got Something?

No. Not yet. I am working on my new menu system but I don’t have anything to offer up yet. Just passing along notes on my experience thus far.

A Book?

I’m going to write a book. A web design book. Or at least that’s the plan. I don’t have any book deal, I’m not pursuing one either. I’m looking to do a proper, self-published book. A friend passed along a magazine article that gave instructions on how to get a book published and up on Amazon.com for under a thousand bucks. Plus I’ve always wanted my own ISBN number.

The math works out that if you can seel about 100 or so copies of the book, the thing pays for itself and everything after is cake. But I’m less about the money and more about the experience. Besides, it seems everyone with a copy of FrontPage is publishing web design books these days. I might as well add more clutter to that field.

But I plan on doing it differently in that it will contain about half design philosophy and half actual examples. It won’t be a CSS book. It will be a web design book. The philosophy half will essentially be an rehash of what I wrote in my Web of Information series (read that from bottom-top… blogs aren’t made for this kind of writing).

The hope is that the philosophy half of the book will still be relevant 10 years from now, whereas the examples half will probably be irrelevant at that point.

But this is just in the “oh, what a nifty idea” stage. And I’m joining the mass of about 4 billion people out there who have that nifty idea. The trick is to actually do it. We’ll see.


By way of another article I poked my head around the One True Layout article. I’ve seen a lot more references to this one article over this past weekend so I wanted to give this a second, more thorough read. The equal height bit especially.

The way the equal height trick works is that each column or block is wrapped with a container that has overflow:hidden; set. Then the block has some incredibly huge value of bottom padding. Negative bottom margins then remove that padding from the flow of the document so that the tallest column doesn’t create a 30,000px tall document. The result is that each column appears to be equal height. In reality the three columns have different heights, but they’re very very tall and are being clipped to give the appearence of being equal height.

This has one immediate advantage that is going to eventually coax me to actually use this hack. It makes adding gutterspace between elements relatively simple. I’ve tried this using the skidoo approach to this in the nausicaa layout but the markup and CSS hackery was just a bit much for me to consider releasing a “production quality” version of the layout.


Relative positioning and negative margins together are becoming the key techniques in the “latest, hot” CSS-based layouts that are out there (the previously mentioned articles being no exception). This approach removes the need for some extra bits of markup that were otherwise utilized to generate source-ordered layouts.

The support across browsing platforms appears to be pretty good too.

Let’s say you’ve got 3 columns and you want the middle column first in your source. You float all 3 columns left. Then add some space to the left of your middle column, either via margins or by shifting the element right X number of units via the left rule in relative positioning. Then take what is to be your left column and move it over the now open area to the left of the middle column via either negative margins or relative positioning.

It seems to work pretty well.

Something Interesting

So I took this method to the minimalist markup ideology and came up with something that might be interesting. It’s quite compatible too. I threw in a couple hacks to get NN4 working with it (yes.. Netscape 4) but IE 5 seems to be pulling the left column just a little too far to the left. Not sure why.

And adding gutterspace inside each column won’t happen unless you introduce extra markup (wrap the content of each column with another DIV and apply padding to that). You could play a bit a trickery and set the side columns to 19% width instead of 20% and compensate all the negative margins and relative positioning values appropriately to get some gutterspace.

This example is only using percent values to specify widths. This is because it’s the only way to get very compatible with the different browsing platforms out there.

The approach is promising. But right now most of what’s out there requires a lot of hacks and breaks under IE 5 and other (somewhat modern) browsers. So the compatibility isn’t there… yet.

IE 7 Phishing Filter

Just an update to a previous post. Sam Spade commented that IE 7’s phishing filter doesn’t sent the full content of the URL, as outlined in this article over at Microsoft.

An important thing to note about the Phishing Filter check is that the information sent to Microsoft is limited to just the web address of the web site. Information associated with the web site address that could contain personal or sensitive information such as search terms you may have entered is removed before the address information is sent to Microsoft.

Another important point to remember is that the URL is transmitted using SSL (Secure Socket Layer) encryption. This is the same encryption used by banks, financial institutions and other organizations to protect their users’ data.

I wanted to test this myself so I setup a packet capturing application and submitted this blog using a URL that contained extra bits of potentially important, private information at the end of the URL.

But as is stated in the quote above, the entire transaction takes place over SSL. So all I could see was my machine talking with which is one of many IPs owned by Microsoft.

If I could decipher the transaction I suspect that what I would see is a url like:


is submitted to Microsoft as:


but I can’t be certain. Is this a problem? In most cases, probably not. What might worry me is that if the full URL (sans CGI query string and username/password) might still contain information. For example, how does Microsoft know where the URL ends and the query string begins? Usually you can go by the question mark (?) if there is one. But there’s also the ability to use forward slashes to separate URL and query string. So something like:

http://weblog.bridgew.edu/ruthsarian/post/username/password/id/ might be itnerpreted as a full URL and not a URL up to the “ruthsarian” part where everything after that is the query string.

And it wouldn’t be an intentional bug on MS’s part, it’s just that some web applications intentionally try to obfuscate the query string from the path to the requested page. But it’s over SSL, so only you and Microsoft would know what got through, if anything.

Still, I’ll be keeping my phishing filter off.

Negative Margins On ALA – 2

Having taken the night to hash over in my head the “holy grail” ALA article I’ve decided I missed or understated the key point of the article.

It’s minimalist markup.

The ALA article layout is doing a 3-column, source-ordered layout with 3 less DIV containers than skidoo too. Now at least 1, but really 2 of those DIVs are there for visual purposes only (adding in a border, padding, etc…) but the fact remains it is heavier on extra markup.

I’ve toyed with minimai markup before and think I might have to take another go at it.

One thing I run into is trying to (ab)use the body element by having it play the role of page wrapper doesn’t really work. IE5 and earlier put the scroll bars for the page on the INSIDE of any borders added to the body element. This means a 200px right border on the body element puts the vertical scrollbar 200 pixels from the right edge of the screen. Now I can see some interesting, experimental uses for doing something like that, but for the layout strucutre I want that simply won’t do.

So I’ll need to toy around a bit. I’ll post anything I put together.

IE 7 Preview

So I bit the bullet and downloaded the IE 7 Beta 2 Preview.

First thing: this overwrites your old IE 6 install. If you want to be able to use IE 6, do not install this preview.

The install was almost painless. The only problem was they’ve added a “verification” step where the installer verifies your install of Windows is legit. The installer hung here for about 5 minutes. But it eventually figured my install of Windows was legit and let me continue. I really dislike that they’ve added that to the install.. but that’s an argument for a completely different thread.

With IE 7 installed, I started it up. It was very slow to start. The overall performance for everything was slow. This is something I’m going to chalk up to it being a beta/debug release and that the final release will respond much better. *crosses fingers*

First Impressions

I hate the UI. They wanted to copy FireFox but be different enough that they could make a case for having not copied FireFox completely. Those differences destroyed the UI.

First thing IE 7 has done is taken the menu that we are all accustomed to seeing in every IE application and removed it. Well actually, no, it’s still there, but now it’s called the “classic menu” and it’s something you need to enable. Furthermore, the “classic menu” cannot be moved above the address bar. This puts the menu in a position we are not accustomed to having. For whatever reason this really really bugs me. The top edge of a window is a visual cue for me. If I want to access the standard file menu, I have the exact position I need to put my mouse cursor, relative to the upper left corner of the window, burned into muscle memory. But now the position has changed and it requires effort to get use to the new location. I really don’t like this.

The address bar that the same features you’ll find in FireFox with a back and foward nav buttons as well as a stop and refresh button. Thing is, the back and forth buttons are on one side, while the refresh and stop buttons are on the other side of the address text box. What’s going on here?! Why are these buttons being separated. This only adds to the work the user needs to perform to access these buttons. Keep these basic buttons in the same area. This way users know to move the mouse cursor to that area even before they know which operation they want to do (back, forward, refresh, etc…) again, we’re talking muscle memory. This is a layout we’ve had since Netscape 1.. why does IE 7 need to break this practice now? To be different?

Okay, that may seem petty.

But how about that search bar. It’s in the upper-right corner, just like firefox. However it comes with only MSN search being supported by default. If you want to be able to use other search engines you have to go to a special page on Microsoft’s website where you can pick from a list of popular search engines. This bothers me as well. It’s an obvious attempt by Microsoft to force users to use MSN search over other more popular search engines. I guess I can’t blame them for it. They are a company and they need to make a profit, etc.. but the whole thing feels a little dishonest.

The tabbed browsing feature has me baffled. I don’t understand how Microsoft could screw this up when they’ve already got some very good examples of how to do this. The button to create a new tab is a blank square. It is positioned immediately after the last window in the tab-bar. Meaning the button changes positions as you add or remove tabs. With FireFox and friends the button doesn’t move. This is a good thing. Why? Usability. Users know where the button is and can quickly access it without thinking. Again.. muscle memory. But since the button moves, you’ve got to hunt it down every time you want to create a new tab.

I also question the choice of icon for the “stop” button. It looks similar to the window close button found in some Windows XP themes. With FireFox the button is made to look different from the normal X you see in the top-right corner of your window. It has a red background, it doesn’t have a square shape, etc… but Microsoft went with a square shape, red X on a grey background. My initial assumption on the functionality of that button was not a page-load stop button but a tab-close button. I don’t think I’ll be alone in that assumption either.

Phishing Filter

This is why I’m coming off as grumpy today. Because of this stupid “phishing filter” feature built into IE 7. The “phishing filter” is a device built into IE 7 which will submit the URL of the page you’re currently viewing to Microsoft. Microsoft will then report back on whether or not that page is a known phishing site.

Sounds reasonable, doesn’t it?

Well.. no. Not really, no.

You’re passing the URL back to Microsoft. That could include sensitive information such as passowords, social security number, maybe sesison IDs which could be used to hijack your session with a given website. It’s a bit of a privacy concern for me no matter what Microsoft says.

So during the first-run of IE 7 I selected to not use this “phishing filter”.

I was then prompted at every page i visited to have IE 7 check with Microsoft to see if the current page was a known phishing site. I had no means to stop these annoying pop-ups. After restarting IE the pop-ups went away. It is my hope that this annoyance is the product of IE 7 being beta and the settings not being properly refreshed in the application.


IE now has an Opera-esque feature that allows you to scale not just the font size, but the entire page, including any and all graphics. Nice. Except that IE corrupts any and all 24-bit PNGs when scaled at any level other than 100%.

I also found that prior to restartint IE 7 after the first-run, IE would break the layouts of several pages when scaled to anything but 100%. This behavior went away with the restart of IE 7.

So what I’m saying is restart IE 7 immediately after you first start it up. That’ll save you some hassle.

CSS Support

So this is what you’re really interested in. How does IE 7 do with CSS?

Well.. it’s too early to tell. The layouts on my site don’t break, but tiny features stopped working or are buggy (like the CSS drop-down menus). This is most likely due to IE 7 having fixed several CSS parsing bugs found in IE 6. This is something I’m going to have to spend time on researching and figuring out just what’s going on.

Another thing I’m noticing is a lot of CSS-based layouts (not just mine) are showing a horizontal scrollbar. When you scroll right the 20 pixels or so that is available to scroll right you see nothing peeking out the side of the layout. So why am I seeing a horizontal scroll bar? Again, probably the fix to the CSS parser is causing IE to not apply IE-specific fixes for bugs like this.

But I haven’t put IE 7 through my own tests yet. I’ll create another post to this blog once I get the chance to do so.

So what’s good about IE 7?

“Quick Tabs”.

It’s an option that is made available to you whenever you have more than 1 tab open. It will display a thumbnail sheet of all the open tabs you have. This is a great feature and it appears to be rock solid. I think it’s obvious where the majority of effort went into developing IE 7.

But that’s it. That really is the only good thing I’ve seen thus far.


Too soon.

It’s beta. A lot of what I’m seeing could be bugs that will be resolved a patch or 2 from now. But I’m weary. The preview release has not inspired confidence in the next generation of IE 7.

Has anyone else tried it yet? Please, share your experiences. I might just be in a very negative mood today and I’m missing a lot of the good.

Negative Margins On ALA

ALA has an article up on the “holy grail” of CSS layouts. It’s a 3-column CSS-based layout that uses negative margins to pull the 3 columns into place.

This may sound familiar.

Unfortunately, this article uses an approach that over-complicates things, is buggy under some browsers, and misses the advantages of a negative margin layout.

For example, the article talks about using padding, not borders, to reserve the space for the side columns. It then goes on to use a really ugly hack to pull of equal height columns.

With skidoo the trick is to not force the three columns to equal height but rather to fake it. Use borders, not padding, to reserve the space for the side columns and apply a color to the borders which acts as a background color for those side columns. It gives the appearence of 3 columns of equal height regardless of which is tallest.

But rather than fake it, this article goes all out to push each column to the same height. How.. well, let’s look at some of the code here:

#container {
overflow: hidden;
#container .column {
padding-bottom: 20010px;  /* X + padding-bottom */
margin-bottom: -20000px;  /* X */
#footer {
position: relative;

If you ever have a column longer than 20,000 pixels (think a really really long article) then your layout breaks using this technique. skidoo does not have this limitation.

Doug Livingstone figured this out a long time ago. And his work inspied the PIEfecta layout Which is what makes the latest PIE article all the more surprising. It uses the hacks outlined in this ALA article, rather than the simpler approach PIE demonstrated 2 years ago.

A lot of the bugs users bring up in the comments on the ALA article are bugs which have long since been resolved.


This article is great for it’s very easy to follow demonstration of how and why this approach works. I can type till my fingers fall off about how the negative margin approach works, but the visual aids supplied in the article offer a nice and easy way to follow the logic.

There’s some creative ways to achieve padding within columns without added markup. I think that might be worth going over. I may have to try make a second attempt at plaine with that and go for three-columns too.

Okay article, but there’s better ways to do the 3-column “holy grail”.

Broken Bits

So the security code bit for posting comments is broken. This is because I upgraded a bunch of software on the server including PERL and I think I need to recompile some libraries used to create the security code bit.

I’ll deal with that sooner than later, but for now if you want to get in touch with me you can hit me up via e-mail at ruthsarian at gmail dot com.

Update: the security code is up and working again. Needed to update the GD library and then reinstall the PERL modulel for it.