Updated Skidoo Too

I’ve updated the CSS and HTML of the skidoo too layout. I received an e-mail from Louise earlier this month who brought to my attention some rendering issues with skidoo too under Netscape 6.2.

After a bit of debugging, I’ve found some fixes.

The first problem was that the footer was not being rendered below the three columns. Rather it was being rendered below the right column. The fix for this was to add a clearing element at the end of the #SOWrap element. Without it, #SOWrap had 0 height because the two elements it contains are both floats. Once you float an element, its height has no bearing on the dimensions of its parent element(s). By inserting a clear inside #SOWrap, that element is forced to recognize the height of its floating children.

Another problem in Netscape 6.2 was that the left-menus would not render correctly on mouse hover. The culprit here (for some reason or other) was setting position:relative on #SOWrap. Removing that fixed the problem, however I need this bit of CSS to fix a text-jog bug in IE. So what I’ve done is changed the CSS selector from #SOWrap to * html #SOWrap which IE will still recognize, while Netscape/Mozilla/All Other Browsers ignore.

What does #SOWrap do anyways?

Good question. Skidoo too is a source-ordered layout. Meaning that the main column, where content unique to the individual page will reside, is placed as close to the beginning in the HTML source as possible. The reasoning behind doing this is that some search engines appear to index only the first 5kb of a webpage. So if your first 5k are navigation elements, chances are the unique content for that page isn’t going to get indexed, and the page won’t show up properly in search results.

Now taking the negative-margin approach to a 3-column layout that we see in skidoo / skidoo too, we can’t put the content column first in the source. Why? Because all three columns are floats. If the main column comes first in the HTML source and is floated left, that means any subsequent, left-floated elements will be stacked to the right (or below if there’s not enough horizontal space) of the main column.

Now we could float the content column to the right, which would allow the left-column to be put to the left-side of the content column. That’s what we want. But then we run into problems with the right-column, which would then be stacked to the left (or below) the content column. Not what we want.

So the solution is to wrap the content column and the left column into a new block element (#SOWrap). Then we can float the content column right, the left-column left, but float the containing #SOWrap element left, allowing the right-column to appear to its right, and thus the right of both the left and content column.

The left and content columns float inside #SOWrap so that their floats will not effect anything outside #SOWrap allowing to float: right the right column without having it stuck to the left of the content column.

Confused yet?

It’s a confusing thing, trying to figure out how floats stack in relation to each other. It might be worth your time to spend a couple hours just playing around with float elements. Don’t do anything complex, just some colored blocks that you float to different sides, and mix up the order in which the blocks appear in the HTML source. You’ll get the hang of things pretty quickly. What’s confusing to read and visualize will become very easy to understand when you see it in action.

Addendum To Drop-Menus

Just a heads-up that those drop-menus I posted recently do not work entirely under IE 5.0. I think it’s just a matter of playing with how the sub-lists are positioned, which I’ll work on and provide an update.

Also, there are some rendering issues with IE and the borders of list items being displayed over sub-menus for some odd reason. I’ve got no idea why this happens and will have to play around some.