Z-index problem in IE 7


I am using the supersized plugin and I have a problem with my page content (navigation and main content divs) going behind the full screen images in IE7

The site can be found at http://www.spiritlevel.co.uk/1LS3

The css is here: http://www.spiritlevel.co.uk/1LS3/css/main.css

The nav and content briefly appear but go behind the images when they load. I have been trying various things to fix it in IE7 but no luck so far - can anyone help me out please as it’s driving me crazy!

It seems to work fine in IE8 and the z-index also seems to be OK in IE6 (although I have a different problem in IE6 with my “#controls” div - being pushed underneath the rest of the page. Not sure why this is happening either…

Any help much appreciated - thanks


I think the problem is that IE doesn’t redraw the screen properly after the image is placed via the javascript. If you grab the corner of the window and move it then a redraw is forced and the elements then show up correctly.

A method I’ve used before is to cause a reflow after a time has elapsed and that seems to make things work again.


Add this script at the bottom of the html.

<!--[if lte IE 7]>
<script type="text/javascript">
 window.setTimeout('fix()' ,1000);
function fix(){
    var el = document.getElementsByTagName('body')[0];
    el.className = el.classname;

There may well be a css fix but I tried the usual suspects without luck.

That page is probably a step too far for IE6 as it doesn’t understand position:fixed. You could try adding a position:absolute here but it won’t be the same as fixed.

    #controls-wrapper {
    margin:0 auto;
    background:url(http://www.spiritlevel.co.uk/1LS3/img/nav-bg.png) repeat-x;
  [B]  position:absolute;[/B]


Thank you so much for your help with this - your redraw script does work which is great, although the delay before the redraw isn’t ideal…

I wonder why the demo of supersized does not have this problem in IE7 whereas my page does?

Supersized - Full Screen Background/Slideshow jQuery Plugin

It makes me think that there may indeed be a css answer that would make the page work without the delay - but until I find that your script is certainly a massive improvement as it at least makes the site useable in IE7 which it was not before.

I tried adding position:absolute; before position:fixed; for the #controls-wrapper but it did not make any difference unfortunately.

thanks again for your help


This bug can have variours triggers and sometimes it can just be that it doesn;t like the way the elements are sitting in the html.

IE7 can be fixed by moving the html for the control-wrapper to the top of the document.

<body id="homepage">
<div id="controls-wrapper">
    <div id="controls">
        <div id="navigation"> <img id="prevslide" src="http://www.spiritlevel.co.uk/1LS3/img/back_dull.png"/><img id="pauseplay" src="http://www.spiritlevel.co.uk/1LS3/img/pause_dull.png"/><img id="nextslide" src="http://www.spiritlevel.co.uk/1LS3/img/forward_dull.png"/> </div>
<div id="logo">
    <h1><a href="index.php">1 Lombard Street</a></h1>

It seems to be something to do with the JS hiding and showing that element and it seems that you could also fix it by making sure that the element is shown again.

<!--[if IE 7]>
<script type="text/javascript">
    $(document).ready(function() {
<body id="homepage">

The conditional comment should follow after the original script as shown above.

Both those seem to work without drawback as far as I can see so have a test and see if it works live as sometimes timings can be different when online.

Regarding IE6 then this seems to work for me.

* html #controls-wrapper {

You sir are a legend! thank you!

Sorry for the delay in replying - I was out for most of the day and didn’t get a chance to try these out till this evening.

I used the first method - reordering the elements and all seems to be well now.

Please can you tell me how you figured out that it was the #controls-wrapper that was causing the problem?

Your IE6 fix works for me too! but I don’t understand why… would you mind explaining why targeting * html #controls-wrapper works but just #controls-wrapper doesn’t?. And what’s with the space between the “#” and “html”?

Thank you so much for helping me with the fixes - seriously appreciated. I’d just like to understand more about why they work so I can learn from it.

I just use my usual debugging technique when I can’t see a reason for the problem. :slight_smile:

I start first with a working local copy that exhbits the problem then I strip the html down to a bare minimum by removing everything but the essentials. I then remove sections one at a time until the bug goes away or reappears. Usually you can spot which element is the trigger and then you can look at the CSS for that specific element and again cut down all css to a minimum.

Eventually you either get to a point where you can duplicate the bug at will but that doesn’t always mean you can fix it. Once the trigger is located then the usual fixes would be haslayout related or perhaps position:relative is needed if overflow is used (in IE7).

Absolute elements have a number of bugs in IE6 and 7 and sometimes the only fix is to move the element into another position. Usually this would be at the start or at the end of the stacking context but is also affected by stacking levels which is why the html worked best at the top of the html in your example.

Luckily, I know most f the bugs and would try the solutions before I need to do all the above but where nothing seems to work then the strip down approach is the only way to go and doesn’t take that long to do as you just keep cutting thing in half to arrive at the final code.

Sometimes it may be that there is no fix but you can at least identify the problem and perhaps a little change of design will allow you to work around it.

Your IE6 fix works for me too! but I don't understand why... would you mind explaining why targeting * html #controls-wrapper works but just #controls-wrapper doesn't?. And what's with the space between the "#" and "html"?

I guess it was a specificity error and adding the * html to the rule gave it more weight. It was also a neater way to provide the hack to IE6.

“* html” is called the star selector hack and is a mechanism for targetting IE6 and under only. It is a valid rule but targets something that can’t exist and should therefore fail.

The asterisk is the universal selector and matches any element type. “html” is just the html element (e.g. html {height:100%}).

So when you say “* html” you are implying that html has a parent which in fact is not true as html is the ultimate parent (root). Therefore the rule should not match any structure in the document.

IE6 and under have a parsing error and assume that when you said * html you meant to say “html” and therefore allows the rule to work. This gives us a 100% safe way to target IE6 and under without having to bother anyone else.

Regarding why absolute works for IE6 rather than fixed isn’t really quite true as absolute will place the element in the right position to start with but once the document scrolls the element will move with the document unlike position:fixed which will never scroll and always stays in the same place.