Anyname Domain Services

CSS and front-end development can be ‘interesting’at times, and shouting at the screen seldom has any affect. I’ve come across most of the IE6 quirks in my time, and used most of the available hacks as well, to varying degrees of success.

The latest to rear its head was one of the strangest. A redraw bug when absolutely positioning a box within the confines of a relatively positioned parent. Nothing strange in that, but the issue was with the other static, relative positioned & float boxes in the same parent and the source order of these divs!

The issue came when trying to seo-ify an ASE template by making the content appear higher in the source order by moving the header to above the footer and re-marking it as position:absolute, and the parent div as position:relative.

The problem can be solved either by removing hasLayout from the offending div – which will be adjacent to the moved AP box, or by placing an empty div between the boxes. Strange behaviour.

I’d never come across this before, but trawling through google came up with a good explanation of the problem. First read the excellent tutorial on hasLayout in IE:
On Having Layout

Then the description of the issue:
IE7-/Win: A box with position:absolute next to a float may disappear

The issue isn’t totally fixed in IE7 and has issues in Firefox, of the same kind but a different nature. The absolute box is correctly redrawn, but in both cases if the offending box contains a HEIGHT:(x)px markup then this is incorrectly redrawn – seemingly as a multiple of itself either above the div or below the AP div. More strange behaviour, inconsistent and maybe linked to clear. When I’ve time I’ll try it with simpler layouts and update this.

In the meantime if you have an issue with redraw in IE7/FF2+ or disappearing AP boxes in IE6 check the content source order and insert dummy non-hasLayout divs between semantic divs.