At Gottabet, we've started to migrate the website to a cleaner, wider layout that I've been working on for the past few months. We started by launching a new homepage and a couple of weeks ago we trialled a new signup page (via A/B test) and then rolled that out for everyone. Yesterday we launched our new Bet Detail Page. This week I'm working on getting a number of the 'basic' pages ported over and after a great start hit one of the most frustrating IE6 bugs for some time. On Gottabet we often absolutely position a 'Bet on it!' button over a bet image in listing pages - so it sits on a corner of the image. Most of the time this works absolutely fine - you have a div containing the bet image and the 'bet on it' link. The div is styled with position:relative and the 'bet on it' link is position:absolute, with the necessary top, left, right or bottom spacings for wherever it needs to sit compared to the image. For the one page I was working on today though, it all went wrong. Very, irritatingly, wrong. The problem: relatively-positioned elements on the page would move from their correct (effectively inline) position in IE6 and shift down a hundred pixels or so and right a bit. To confound matters further, I found that it depended on whether I refreshed the page while looking at the top or the bottom of the page in the browser. When scrolled to the top, the relative elements moved down on refresh. If scrolling to the bottom of the page and hitting refresh, on reload they'd be too high. After searching for known issues with IE6 and position:relative, I found a couple of common problems that didn't seem to apply to me: the peek-a-boo bug and hasLayout. The hasLayout issue seemed close, but the div with position:relative was already triggering hasLayout thanks to having a specified width and float:left. The symptoms also didn't quite match up (mine seemed much weirder). In the end, I resorted to what I should have done much earlier and set up a test page with an extremely stripped-down verson of the page content - only the bare minimum of the grid layout with no header/footer and only the CSS relevant to the part of the page that was breaking. It worked fine. This was a good sign, because it at least meant there was definitely something causing the problem, so I started adding code (and the relevant styling) back in until it broke. Turns out a containing div had position:relative on its own, with nothing to trigger hasLayout in Internet Explorer. It didn't affect the case where it was being used, but by the time it filtered down to the next relatively-positioned block things were going crazy. After 3 hours (most of them going round in circles before I started the stripped-down HTML version - there's a lesson), all it took was adding a width to that containing div to trigger hasLayout in IE and all was well once more. So be warned: the hasLayout bug gets nastier when you have nested blocks using position:relative!