I wrote a 'contact us' webform for a customer, for which most content was normal flow, some contained floating elements and a there were a couple of absolutely positioned divs.
Nothing extraordinary, no hacks, and FFox, Safari, Chrome and even Opera all dealt with it exactly as I expected, without any problem.
IE... a blank page... WTF ??
After much screwing about, I managed to resolve the display of the normal flow content, by setting the containing div display types to 'inline-block' - which meant that all the other browsers were immediately unhappy... so I worked around that by forcing IE7
compatibility mode and using expression(‘inline-block’) so that the other browsers all continued to work.
**EDIT: A bit more time with it, and I realised that this is the age-old 'has-layout' problem of IE, as the divs have position:relative and width/height settings of auto... so IE fails to display them. The 'inline-block' for IE is a trigger for 'has-layout'
which allows them to be displayed. Once I recognised the problem, I realised that I could eliminate the stupid expression() hack, and instead implement the trusty old 'zoom:1' hack... to give IE it's required 'has-layout' status, while using display:block...
and not bog down the page with expression() scripts.**
However... the AP’d divs were still missing... so more experimenting and sleuthing ensued... and after many MANY wasted hours and banging of head on the desk... I finally found that when IE encounters an AP’d div that has a sibling which is not AP’d and which
contains a float... it just doesn’t display it. What clued me into the problem was that when inspecting the html with the developer tools, and clicking on the AP’d node, it would suddenly appear on the screen... like it needed a wakeup call. Anyway, more experimenting
and I found that putting an empty <div></div> in between the two gave it the smack up the side of the head required, and IE finally looked the way all the other’s looked on first try.
I then did some hunting about on the internet, and found that this mess has been around since the olden days of IE and is *still* not fixed... so I went back and check the original problem against IE7 and IE6 and, sure enough, they has the same issues and required
the same solution.
Much as I’d love to believe MS are going to sort this all out before IE8 is released, I'm already starting to resign myself to 4-5 more years of IE-Work-arounds, as these are both problems we've been living with in IE since V5