If you view this page in IE7: http://65.60.10.2/~marionin/ , why are the light purple headers ("Spotlights", "Serendipity Projects", "Marion Institute Blog") hiding underneath the dark purple band?
I have firebugged till my fingers hurt, but I can't figure it out. The column divs are written after the block div, so they should display on top.
Mucking about with the z-index doesn't help, even when setting the positions of the block and the columns to relative.
[Of course, as would be expected, everything looks fine in Firefox, Safari, Opera, and Chrome.]
Thanks for any help!
IE has terrible z-index bugs that are often impossible to grok. I was able to make it behave in IE 7 after some fiddling with the IE developer toolbar.
I noticed that for some reason many elements had z-index defined on them yet these weren't appearing in the HTML. Do you have a script running that is setting any z-indexes? I noticed that they were in reverse order, meaning that the high level elements had higher z-indexes than the lower level elements. This is one way to create numerous bugs in IE. The deeper the HTML appears in the hierarchy, the higher its z-index should be.
I started by removing the z-index on the relevant containers, from body down to the two <div>s in #main-content. I set position: relative on #main-content but left z-index undefined. I set position: relative on the two <div>s in #main-content and set the z-index to 100 and 200 respectively.
Within #content, the first <div>, I added z-index: 110 and the second <div> (the row of blocks with small pictures) I added z-index: 120.
That seemed to get IE 7 to behave correctly.
If there is anything else that has a z-index defined that I didn't mention, try removing it and starting from the ground up. The less elements there are with z-index defined, the less opportunity there is for IE to behave badly.
#block-block-11 {
position: static;
}
...quick fix to a larger issue eloquently detailed by CalebD.
Related
The nav of a website i have in production works as 3 tabs, each of the 3 corresponding content coming forward on click.
I just realized it doesn't work on Chrome 22 (although i'm 90% sure i tested it on Chrome a year ago when the site was brought online), but is perfectly fine on IE9 and FF16.
Here is a summary of my problem : http://jsfiddle.net/be7mQ/3/
As you can see, only the last tab of the 3 can be hovered (and therefore clicked) on Chrome 22.
It's like Chrome created a new z-index stack for each .tab-container instead of just showing all elements with z-index:21 above the rest of the content.
All the elements are either position:fixed or position:absolute and i can't see what's wrong there, anyone?
It's like Chrome created a new z-index stack for each .tab-container instead of just showing all elements with z-index:21 above the rest of the content.
This behavior was deliberately introduced in Chrome 22. Boxes with position: fixed will create new stacking contexts in WebKit-based browsers regardless of their z-index, causing the behavior you're currently seeing.
More on that here. It is said that it is being proposed as a revision to the CSS2.1 spec to aid mobile implementations (the same behavior already occurs on mobile WebKit browsers); it was addressed to some extent in this set of minutes but there hasn't been any actual change to the spec yet as I've seen — indeed; the working group hasn't reached a consensus yet.
I for one agree with Microsoft's compatibility concerns; I can see this breaking a sizable portion of modern sites. The problem is exacerbated by workarounds basically being situational and totally dependent on the nature of the affected layout, as demonstrated by the other answers here.
BoltClock's answer was the one, and as previously written, each case will need a specific fix to this, but this is how i solved my own broken site :
http://jsfiddle.net/be7mQ/13/
i.e. put all my previous position:fixed divs in one only position:fixed parent #tabs that has z-index:1 to force a new stack on browsers other than Chrome22.
This way, within the new #tabs element i'm free to play with z-indexes again as before.
Remove height: 100% from .tab-container. The height of the third tab is covering up the previous two. When I did this in your fiddle they were all clickable.
Since you're using position fixed, the top: 0 property will make your last element hover all others. Instead of positioning your tab element, change the top of your tab-container, as follows.
Change your HTML to
<div class="tab-container info">
<div id="info" class="tab">I<br/>N<br/>F<br/>O</div>
</div>
<div class="tab-container news">
<div id="news" class="tab">N<br/>E<br/>W<br/>S</div>
</div>
<div class="tab-container shop">
<div id="shop" class="tab">S<br/>H<br/>O<br/>P</div>
</div>
and your CSS to
.info{
top:0px;
}
.news{
top:100px;
}
.shop{
top:200px;
}
Fiddle
Because you are using
height: 100%
on the .tab-container{, the last one is overlapping everything else hence only the third(last) one works for hovering. Try removing the height: 100% from your css for tab-container. It works!
The following example is a very simplified version of my top navigation.
http://jsfiddle.net/AEqxT/
If you look in most browsers, you should see two green list items next to eachother, with a blue box or 'badge' sitting on top, bridging the gap between the two. In IE7 however, the blue box always falls below the second li. I've tried all manner of fixes to this. Setting a higher z-index to the parent ul didn't change anything, and if I use position: relative; on the 'badge', it loses its width and height.
Is there an obvious fix to this that I am missing?
You'll probably struggle with your badge in with the LI, take it out of the list and you should be ok, with a bit of messing with position:
http://jsfiddle.net/AEqxT/2/
If you absolutely have to have it in with the LI, then you'll probably have to have some JS to make this work
This is a reported IE7 bug.
You could fix it with the JS solution posted to this question, or you could manually set different z-indexes to all <li> element, ordered from high to low values:
http://jsfiddle.net/AEqxT/3/
Ok, I'm stumped!
If anyone has a suggestion or two on a CSS / JavaScript fix for an IE7 z-index issue on this page without changing the DOM structure much (it's set up for easy tab usage) I'd be incredibly happy to try it out.
On this page, IE7 renders the bar that spans 100% of the width of the page above everything else, while I actually need to cram it very specifically between the text and the hero image (as seen when viewed on any modern browser).
Here's the link.
Thanks.
IE7 has known bugs with z-index, see: IE7 Z-Index issue - Context Menu
In this specific instance, you can fix it by changing a few parts of your CSS. Complete each step and check the progress as you go:
On #container remove position:relative .
The z-index issue is now fixed, but everything is in the wrong position!
On #thumbnails and .pane_img remove these properties: position, top, left, z-index.
On .pane_content, set left:50%; margin-left:-480px; bottom:90px.
On #learn_more_btn and .renova_logo, repeat the left: 50%; margin-left: ??px method to place the elements back where they should be.
I am trying to make a table-like calendar page, using fixed width and height block level elements. There is an outer container, which sets the width, and the cells get aligned by float: left. It works well in every browser, except in IE6, where the list gets split after the 29th element.
If I make the outside container a bit more wide (by at least 3 pixels) the problem gets fixed in IE6. Because the elements are more than 3 pixels wide, it doesn't change how the page looks. But I really don't understand why it happens, and what should I do not to make it happen.
I tried IE7.js, but it didn't help.
I know IE6 is such a buggy old browser, but while my sites are simple I prefer making them IE6 compatible.
link to the page in question
You can fix it by adding this to the bottom of style.css:
/* IE6 hack */
* html #naptar-list a, * html #naptar-list div {
width: 77px
}
This works by using the Star HTML hack to feed to only IE6 the declaration width: 77px (1px less than the actual width), which in my testing, fixed the problem: I'm not entirely sure why.
http://madisonlane.businesscatalyst.com
I'm trying to get the div#sign-post to sit above the div#bottom. This works fine in all browsers except IE6 & IE7. Can anyone see what the problem is here?
Also IE6 is displaying an additional 198px to the top of div#bottom.
Most of the answers here are wrong; some work, but not for the reason they state. Here is some explanation.
This is how z-index should work according to the spec:
you can give a z-index value to any element; if you don't, it defaults to auto
positioned elements (that is, elements with a position attribute different from the default static) with a z-index different from auto create a new stacking context. Stacking contexts are the "units" of overlapping; one stacking context is either completely above the another (that is, every element of the first is above any element of the second) or completely below it.
inside the same stacking context, the stack level of the elements is compared. Elements with an explicit z-index value have that value as a stack level, other elements inherit from their parents. The element with the higher stack level is displayed on top. When two elements have the same stack level, generally the one which is later in the DOM tree is painted on top. (More complicated rules apply if they have a different position attribute.)
In other words, when two elements have z-index set, in order to decide which will show on top, you need to check if they have any positioned parents which also have z-index set. If they don't, or the parents are common, the one with the higher z-index wins. If they do, you need to compare the parents, and the z-index of the children is irrelevant.
So the z-index decides how the element is placed compared to other children of its "stacking parent" (the closest ancestor with a z-index set and a position of relative, absolute or fixed), but it doesn't matter when comparing to other elements; it is the stacking parent's z-index (or possibly the z-index of the stacking parent's stacking parent, et cetera) which counts. In a typical document where you use z-index only on a few elements like dropdown menus and popups, none of which contains the other, the stacking parent of all the elements which have a z-index is the whole document, and you can usually get away with thinking of the z-index as a global, document-level ordering.
The fundamental difference with IE6/7 is that positioned elements start new stacking contexts, whether they have z-index set or not. Since the elements which you would instinctively assign z-index values to are typically absolutely positioned and have a relatively positioned parent or close ancestor, this will mean that your z-index-ed elements won't be compared at all, instead their positioned ancestors will - and since those have no z-index set, document order will prevail.
As a workaround, you need to find out which ancestors are actually compared, and assign some z-index to them to restore the order you want (which will usually be reverse document order). Usually this is done by javascript - for a dropdown menu, you can walk through the menu containers or parent menu items, and assign them a z-index of 1000, 999, 998 and so on. Another method: when a popup or dropdown menu becomes visible, find all its relatively positioned ancestors, and give them an on-top class which has a very high z-index; when it becomes invisible again, remove the classes.
Agree with validator comment - validating usually helps. But, if it doesn't heres a few pointers for z-index in IE:
1) elements who's z-index you're manipulating should be on the same level ie. you should be setting the z-index of #bottom and #body
if this is not feasible then
2) IE sometimes wont apply the z-index correctly unless the elements ou are applying it to have a position:relative. Try applying that property to #bottom and #body (or #signpost)
let me know how that works out
Darko
I just had this problem and the fix I found (thanks to Quirksmode) was to give the direct parent of the node you are trying to set a z-index of it's own z-index that is at less than the z-index of the node you are trying to set. Here is a quick example that should work in IE6
<html>
<head>
<style type="text/css">
#AlwaysOnTop {
background-color: red;
color: white;
width: 300px;
position: fixed;
top: 0;
z-index: 2;
}
#Header {
color: white;
width: 100%;
text-align: center;
z-index: 1;
}
</style>
</head>
<body>
<div id="Header">
<div id="AlwaysOnTop">This will always be on top</div>
</div>
<div id="Content">Some long amount of text to produce a scroll bar</div>
</body>
</html>
Welcome, I solved the problem with:
.header {
position: relative;
z-index: 1001;
}
.content {
position: relative;
z-index: 1000;
}
Looks to me like you have some malformed HTML in there. I tried counting, and perhaps I lost count of the opening and closing tags, but it looks like div#container isn't closed. Try running your page through a validator (such as W3C's HTML Validator, or something) and fixing some of the errors. That's helped me with these sorts of problems in the past. Good luck!
I've recently had an ongoing problem displaying one layer above another. In my case I was programmatically creating two layers in Javascript, one for diaplaying a custom control and one for creating a full screen layer behind it. FF was fine, bu IE displayed the full screen layer always on top of everything else.
After numerous trawls over the interweb, trying everyone's suggestions, the only way I eventually get it working was to remove position: attributes from both layers, and tweak the margin-top: attribute until I got a satisfactory result.
A bit of a hash, but it works and it'll be fine until IE 8 sorts out all of the current bugs......
the only reliable solution is, to put the top elements below in the code and then push them over the other stuff with absolute positioning.
e.g. Wordpress:
put the navigation in the footer file, but still inside the page wrapper.
might also bring some advantages for search engines, because they can directly start with the content, without crawling through the menu first...
UPDATE:
I need to correct myself. While putting the element below and then pushing it over is still the easiest way, there are certain cases when this is not possible in reasonable time. Then you have to make sure that each and every parent element has some kind of positioning and some senseful z-index. Then the z-index should work again even in IE7.