Kimler Sidebar Menu

Kimler Adventure Pages: Journal Entries

random top 40

z-index on a:hover elements

Filed in:CSS
The Web

z-index on a:hover elements

September 11th, 2005  · stk

An(other) IE6 Shortcoming

UPDATE 10-May-2006: Thanks to Stu Nicholls & ¥åßßå, I have found an effective work-a-round for this IE z-index issue. (See the solution).

I developed the second, more advanced version of the pure-CSS Photo Zoom (PZ2) in mid June. Besides our long summer vacation, one of the reasons I haven't yet published a 'production version', has revolved around a couple of problems with MSIE. I've found a work-a-round for one, but the other issue - a Z-index change on hover - remains.

I believe that the problem is "unsolvable". The work-a-round is not ideal, as it adds unnecessary complexity and limits PZ2s application. I am not happy. >:(

I blame it all on Microsoft's poor support for CSS standards.

At issue: IE's inability to support a z-index value change for a hovered element.

For an explanation and demonstration, as well as an IE "fix", read on...

A Explanation and Demonstration

The main advantage of PZ2, over the original, is that in PZ2 the zoomed image overlays the text, instead of shifting the text to make room for the zoomed image. This is demonstrated below. (Note: There are some caption styling differences between the two, which can be changed, in the CSS file, to be alike.)

The image on the left zooms using the original and the image on the right is zoomed using PZ2. With the original, the larger the size difference between the thumbnail and zoomed image, the more the text has to shift, which can be jarring & disorienting. (Of course, as my wife has pointed out, using the original zoom, one can still READ the text, while looking at the picture ... which can't be done using PZ2 ... perhaps, the older version is preferable in some applications?).

Using PZ2 with a single photo, there generally isn't a z-index problem. It's not until multiple photos are used, which overlap each other upon zoom, that the z-index problem using PZ2 becomes obvious.

Z-index is a CSS property that places elements in front (or behind) one another. It's a seldom used and often confusing property, mainly because it only affects positioned elements (meaning that the element MUST be either relatively or absolutely positioned, or z-index won't do a thing).

If this is a property that you've struggled with (I know I have), a key thing to remember is that an element can be easily positioned with a "position:relative" declaration, without affecting its placement on the screen. So, when using z-index, make certain that the element is positioned and if it's not - apply a "position:relative;" declaration.

Look at the multiple photos below. No z-index consideration has been made. When you zoom the left-most photo, you see that it doesn't overlay the ones next to it. This is because each element placed on an XHTML page has an inherent z-index that is higher than what precedes it - meaning that each successive element is "placed on top" of the element before it. Make sense?


Normally, elements don't zoom on hover, so this inherent z-index assignment isn't a problem. However, it looks pretty crappy with PZ2 and needs to be dealt with.

Easy. Assign a low z-index value to all un zoomed PZ2 photos on a page. Then, assign a high z-index value to the PZ2 photo that a mouse is hovering over (only one photo can be zoomed at any given time).

Of course, FireFox (a more modern browser), which follows the CSS standard more closely than MSIE, doesn't have a problem with this declaration. MSIE, however, can't make heads or tails of the declaration and so - ignores it. Look at the photos below. If you're viewing in Firefox - no problem - things look good. If you're viewing in MSIE - problem - things look just like they did above ... YUCK!


The IE "FIX"

After banging my head against the wall and trying a bunch of different things, some of which involved some very loud cursing, I came to the conclusion that I'd have to play games with IE and that PZ2 would suffer slightly, as a result.

The fix involved numbering each successive PZ2 photo on a page and REVERSING the inherent z-index values, by assigning a lower z-index value to each successive PZ2 photo.

The results can be seen below. Now the zoomed images look fine in BOTH Firefox and IE.


The solution works, as long as a zoomed photo doesn't overlay any previous photos. It also 'breaks' if a zoomed photo, at the end of one entry, overlays the first zoomed photo of the NEXT entry. (So, you see, there are limitations with this 'fix' ... which is why I still direct my ire at Microsoft, for not supporting the CSS standards). Grrrr. :>

The Future

With the beta 1 release of IE7 (July 27, 2005) there is much hope that this version will make up for many of the CSS shortcomings of IE6. As you can read on the IEBlog, there are a bunch of standards support issues that will be addressed in IE7, but unfortunately, many will also remain.

I'm afraid that changing the Z-Index on a hovered element, will be around for some time to come.

Again .... grrrr. :>

Regarding a production release of PZ2 - I'm still working with the code, stabilizing, pruning and adding small features. I've been using it on this blog for the past few entries and the code has been improved markedly. It's now just down to the final testing and should be out shortly. Stay tuned!

10-May-2006 Update

I noticed that Stu Nicholl's Photo Gallery Mk.3 doesn't have a z-index overlay problem. Upon closer examination, I understand why. It's not something that I had ever considered and it shows the power of collaboration on such issues.

Normally, when positioning elements absolutely, I place them INSIDE a relatively positioned element. Doing so resets the origin point to the relatively positioned parent and then one can position the absolute element, within the parent, by using the [ top | left | right | bottom ] properties. However, if one positions an element absolutely, and doesn't use any of the aforementioned positioning properties, it remains fixed at it's original location on the screen (though taken out of the document flow). By using margining to position the element, it's done from THAT location (not the parent or page origin) AND ... the key part ... there is no IE z-index problem in assigning the hovered element a large z-index value.

Have a look at the example below, to see what I mean.


Note: the middle image in this example is margined to open closer to the center of the image, which means that it will covers BOTH the left and right thumbs. This configuration is NOT possible, using the earlier "fix" (as it only reverses the natural z-index order) rather than assigning a "highest" z-index value to the hovered image.

**Also: the image elements cannot be placed inside a relatively positioned parent, otherwise the IE z-index issue returns.

Hope this helps! It did me, as this technique is now employed in the (best yet) 3rd version of Photo-caption Zoom.

Views: 115387 views
29 Comments · GuestBook
default pin-it button
Updated: 24-Jul-2008
Web View Count: 115387 viewsLast Web Update: 24-Jul-2008

Your Two Sense:

XHTML tags allowed. URLs & such will be converted to links.

Subscribe to Comments

Auto convert line breaks to <br />

1.flag Lewis Comment
Giving it a border appears to work too. Even a 0px border will work.
2.flag stk Comment
What's "it"? Most of the image tests above HAVE a border (on the image) and it still fails in IE.

If you've got a link to an example, I'm all eyes, but as you can see, having a border on the image does nothing to solve the problem.
3.flag Jonathan Haun Comment
I found that if you use the hack:

html*#whatever { z-index:1 } for IE, this works on some things. I didn't try it on this, but it's helped me out with z-index stuff in the past.
4.flag stk Comment

Thanks for writing.

That hack selects ALL descendants of the HTML element in IE7 and lower, and it uses invalid CSS to do so. (i.e., your CSS won't validate, as you'll get a PARSE ERROR).

Regardless, flattening every element in IE won't fix the IE BUG, which is about SWITCHING z-index for any hovered element (i.e., from a { z-index:1 } to a:hover { z-index:2 }).


5.flag Gordie Comment
I'm trying to make a 'stack' of images change, depending on where the mouse is over the area the image is displayed on.
I have a rough version of this using image maps at
However, the complete functinality works only in firefox.
For example, if you roll over 'Luggage' a new image shows up.

I can't seem to do more than a simple rollover in css, can you help?
6.flag stk Comment

You might want to have a look at this post.

Yes, I'm sure I can help. Just contact me and I'll help you get what you want.

7.flag Paul Comment
Thanks a million! This hack solved a very pesky problem I was having where we were attaching drop down menus to images. In IE, menus would appear under the next image, but your hack fixed the issue. I cant tell you how much stress this issue caused me. Thanks for relieving it!
8.flag stk Comment

You're welcome and glad it helped. LOL, if only the thanks were a "million" dollars, eh?

Nice: A link-back to

Nicer: A PayPal donation to skimler·at·yahoo·com

9.flag Gerwin Comment
Hey, thanks heaps for the fix. It worked perfectly for what I'm doing. In the CMS I'm building, the image manager displays the images in-window and when you click on an image, it brings up a menu with editing options. As you can imagine, the menu in IE went under the other icons. I did what you recomended and it worked great!

Here's some screen shots!

Thanks Mate.


10.flag stk Comment
Gerwin - Glad to hear that the technique helped. It's a frustrating problem and an intriquing solution, eh?

Thanks for commenting and posting the results. I'll embed the images, so you no longer have to worry about hosting them.

Cheers - stk
11.flag Gerwin Comment
Absolutely. It's definitely a frustrating problem and it's often one that can't go ignored and indeed a very good solution.

Cool @ hosting - that'd be great.

Thanks again,
12.flag Bish Comment
Lewis wrote:

Giving it a border appears to work too. Even a 0px border will work.

This worked for me too. Applying {border:0px solid (colour);} to both the a and a:hover in question fixed every single z-index rendering sin I’ve encountered while developing a complex graphical navigation panel from an ul using a Remote Linking technique.
13.flag stk Comment
Bish said:

This [Giving it a border ... Even a 0px border will work.] worked for me too.

Below I've applied { border:1px solid red; } to the a and a:hover in question, as you claim worked for you. (I also raised the specificity - using an additional ID selector - and made the border visible, to insure that the border CSS is overriding other CSS and that it's being honored.)

Clearly, adding a border does nothing to solve the z-index on:hover issue in Internet Explorer.

You say "it works". Please show me. I am interested in finding other ways to solve this IE "changing-z-index-value-on-hover" problem, but please link your solution, rather than simply stating "it works". ;)

14.flag Gareth Comment
Aha! Thanks for this little tip.

I've been having a bit of trouble with CSS dropdown menus for a client and, of course, IE is a swine with z-indexing when the menus cover any other positioned elements further down the semantic flow.

With a bit of margin jiggery and removing the relative positioning of the menu, the menu items now work perfectly in all browsers.

15.flag Robert Comment
can a text link be used, instead of a graphic thumb? I've tried to replace the graphic within the href with text, but its not working.
16.flag stk Comment
Robert - I'll need a link or further information to understand what it is you're trying to do/achieve.
17.flag Robert Comment
actually, I worked it out. However, in this example,
what I'm actually hoping to do is make the text that shows on the left actually text.
Is there a way to do that with the caption option?
that way, I could have a modified graphic along with text, which would optimize the page for SEO.
18.flag Joe Comment
Thanks for this article. I used your idea of giving each image a different z-index to solve a problem I had with the IE Z-Index bug on our web site Campus Talks list.

I listed the talks, one per line, with CSS hover stlye links to a summary, video, audio and transcript.

Everything worked well in all other browsers except IE, it allowed the links from the following talk to show through the hover, making the hover text unreadable.

The solution, I gave the div that contained each talk/links set a Z-Index value in decending order. I placed this Z-Index in the HTML file in an Inline stlye for each div, as such,

Talk No 1
div stlye = "z-index: 50"

Talk No 2
div stlye = "z-index: 40"

Talk No 3
div stlye = "z-index: 30"

Talk No 4
div stlye = "z-index: 20"

Talk No 5
div stlye = "z-index: 10"

This is for a text file of five talks. I will n ow apply this to our entire list of 1000 talks, using PHP and a template to give each talk the correct Z-Index.

I hope this is usefull to anyone else having the same problem.

Now for the political bit: I think Bill Gates should be tied to the nearest telephne pole and flogged with a thousand wet spegetti noodles.
19.flag Joe Comment
I have created my list of 1000 talks and everything is working well in all browsers, except for, yes-your favorite and mine-Internet Explorer.

The z-index is now working correctly in that browser and the links from the following talk do not show through the hover of the selected talk.

However, it now takes until the count of 1000&3 for the hover to show when the mouse is put over the link in that browser.

All of the other browsers I test: FireFox 3.0.5, Opera 9.6, Safari and Google Chrome display the hover text almost instantly.

IE works fine when the list is only 5 talks long, but with over 1000 talks it is going slow and even crashing. It is possible that I have an error on the page that is troubling IE, however, I have the HTML Validator plugin installed in FireFox and it is giving my list a clean bill of health, showing the page to validate.

If anyone wants to venture a guess as to why I am having this problem I will post a link here if you have time.
20.flag stk Comment
Joe - A link would help! :D
21.flag Joe Comment
Hi stk,

Here is a link to the current page:

This page works properly in all browsers now, as far as no links show through the hovers. However, in IE7, there is a delay from the time the mouse is placed over the lnk text and the hover is displayed of approximately 3 seconds.

I recieved some advice from the Webmaster World blog and here is a link: so you can see the discussion there if you like.

I did a few tests and discovered that if I reduced the list to around 300 talks the delay in almost unnoticeable in IE7.

I can only imagine that it is IE's z-index stack that is to blame here. Because all of the other browsers, FF3, Opera 9, Safari and Google Chrome do not have a delay in displayiing the hover and they handle the z-index stack order properly, I can only deduce it is IE's z-index bug.

However, the suggestion on Webmaster World was not to use a z-index at all and if you look at the last post by alt131 you can see his verison of my code without the z-index.

I tested his code and although I do not get the links showing through the hover, the delay is still present.

The first link above is to a version of the talks list with the z-index set.

22.flag stk Comment
Joe - I've looked at your links. Here's are my intial thoughts:

1) At around 1.1 MB, the page is WAY too big, especially considering it contains no real graphical data. (To compare: our main page is currently in the 300 KB range - which I consider "heavy" - and individual articles aren't generally more than 100 KB and that's with lots of graphical data.) I know that many sites recommend 50 KB pages, but in today's world, that's a tad harsh. With text-only data, however, you should be able to include a lot and still keep pages around 100 KB.

I recommend organizing the talks in a way that reduces page-load and ALSO allows visitors to quickly find the talks which interest them. (Topical grouping? Numerical grouping? Chronological grouping? I don't know. Something.)

A search function would help. (735+ talks to paw through is a very deep data stream in which to wade). ;)

2) I'd eliminate the table wrap (unless it's absolutely needed?)

3) Some "Summaries" link to "Not Available". If you unlink them (not underline them), that'd help lighten the code.

4) In the same vein, Video and MP3 each have the same two options (watch|listen and download). Why have pop-ups links for those? Using 4 linked icons, which could be CSS rollovers, you'd eliminate more overhead.

5) Oh ... FYI - It's possible (we're doing this) to serve up GZIP'd - compressed - HTML/CSS/JS pages, which helps reduce page-loads. (The idea is that the page is requested, the server sees that the user agent - or browser - can accept GZIP files and sends a compressed file across the Internet, which is uncompressed after it's received. It's offers loads faster download times than sending uncompressed files). ;)

I've not looked into the CSS or XHTML to see if can be improved, speed-wise/code-wise ... but I'd address the basic usability issues first (i.e., lighten page weight + find a way to help visitors quickly sort through 735+ talks).

Hope this helps.

P.S. - As this isn't really an IE z-index issue, please - email me if you'd like more help, instead of posting here. Thanks. :)
23.flag Joe Comment

Thanks for your comments. There is a lot there and it all looks very helpfull. I will confer with my client about spliting up the list.

I will do as you say regarding further help and e-mail you if i need it.

Thanks very much,
24.flag Robert Comment
OK, I got myself in another fix:
I'm trying to do the hover-thing from a li hover entry, not a div, this time.
This link will probably make more sense:

For example, I'm trying to get 'my account' to do what 'on demand' does, on hover.

Not having much luck with this one. Any help?
25.flag James Comment
How would I do it if I wanted to have a menu along the top which said "picture 1" "picture 2" and "picture 3", and have each picture zoom when I hovered over the words instead of the when I hovered over the picture?
26.flag Robert Comment

I did something similar, which can be found at this link. You can also see a text link version at

The link has to contain all the elements that are displayed, when it is rolled over. The trick is that each x/y has to be made in relationship to where that link is in order for the image(s) to show up in the same location. I have not found a work around to this one inconvienience (css-wise). As such, it's much easier if you space your links in easy multiples, like 10px. That way, each enlarged image placement only has to have 10px added to its x or y (top or left) value, to achieve alignment (of the image, not the universe).

27.flag Topher Comment
Thanks for this explanation, I trawled through a lot of articles telling me that IE's z-indexing was just broken but removing all the surrounding relative positioning worked for me.
28.flag Cleb Comment
Thank you. This saved me a lot of hitting my head against the table.
29.flag Perry Comment
Thanks very much. Best explanation I've read in a long while.