The funny thing is that there’s nothing new about CSS tables. I don’t know why I haven’t encountered them before, because they work fine in most browsers. Probably because the idea of tables and layout leaves a taste of sick in the back of most peoples mouth? This book proves me wrong, it explains with good examples how the CSS tables properties work, how they compare to the old ways of positioning and floating, and why it’s the next big thing.

The reason why the authors reckon it’ll be huge is the forthcoming release of IE8, which will be the first IE to support CSS tables. Obviously it’ll take some time before IE6 and 7 are gone, but that’s no reason not to play with our new developer toys!

The book finishes off by looking into the future (CSS3), showing examples of what CSS will look like when we get to use the Template Layout Module (formerly Advanced Layout Module), Grid Positioning Module and the Multi-column Layout module. The way of writing CSS using these differs radically from the usual floats and positioning, and using CSS tables seems like a good in between step to me. So if you’re serious about your CSS and want to avoid skill rot this book is an easy first step onwards.

Just got a tweet saying I won SitePoint’s new book Everything You Know About CSS Is Wrong. That is the one CSS book that’s come out recently that I feel any need of reading. As it is, I’ve done my fair share of CSS, not that I mind, not at all. I’ve long reached the point where I know which browsers has which bugs and how to combat them without my brain exploding. Most of the time anyway.

So I’ve finally taken the plunge into JavaScript. I know, it’s like starting a blog in 2008, but better late than never, right? And literally as I’m going through the last pages of Jeremy Keith’s DOM scripting (friendly lent from Man With No Blog) Twitter tells me they’ve picked a winner, not mentioning who the winner is. Easily distracted as I am I follow the link, read the whole post, and don’t realize I’m the lucky one until I read my own name towards the end. Never mind that they’ve screenshotted my twitterbadge all over the top. I just thought that was some new integrated twitter API thing displaying that I’m logged in. So in one word – yay!

Looks like I’m getting some visitors via the SitePoint blog and my twitter profile. Hi guys and girls!

Now you have your perfect semantic validating SEO friendly nested list in order to make the drop-down menu the client wants. The CSS is in place and the dummy you’ve thrown up works.
But when you implement it into the site the drop-down partly hides behind the content further down. Offcourse – it has an higher z-index. Easy fix. But then the juggernaut IE comes along and crashes the party.

In all IE, any element that has position:relative and haslayout=true
forms a stacking context. This is not correct, it would need to have a
z-index to act as a stacking context.

Assume you have two stacking contexts:

• B follows A.
• B is higher in the stack, nearest to the user.

A
B

No matter what z-index you choose for it, a child A-x will never leave
its stacking context A.

A. A-1, A-2, A-3 ….
B

No child of A will ever be higher in the stack than B.

A real life example

In my case I had a #header which erroneously formed such a stacking context,
because of

#header {position:relative; width: 920px;} /* haslayout = true */

And there is a regular stacking context following:

#main {position:relative; z-index: 1}

Thus:

#header
#main

No matter what z-index I chose for it, a child (#menu) of #header would never
leave its stacking context #header.

#header #menu
#main

The #menu inside of #header would be painted over by #main. And even if
#main is transparent, the drop down #menu will loose mouse focus and
collapse.

The solution

What it finally came down to was to apply z-index: 2 to #header, to
have the entire #header higher in the stack, nearer to the user, than
#main.

Thank you:

I could have never done this without the help of Ingo Chao and the ever useful css-discuss list.

• position: relative
• zoom: 1
• height: 1%

They are all due to Microsoft’s proprietary concept of hasLayout.

Feel free to add any other magic bullets in the comments.

This is the trouble line: <a class="link">Les mer<⁄a>. For an anchor tag to take effect, it has to have the href="" attribute set, otherwise the link won’t fire and it seems that IE6 isn’t
acknowledging your <a> tags without href, hence your lack of :hover effects.

What a headslapping moment. I was so fixated on the problem being with IE6, that I didn’t realize the problem was in the chair.