I know there is the bug where absolute elements appear above relative ones. However I am getting the reverse of this issue.
The z-index on the "bottom" element is 1 and has a position:relative assigned. The top element has absolute positioning and a z-index of 99.
This works fine in Firefox, Webkit based browsers and IE8. Any ideas about why this could be happening?
In Internet Explorer positioned
elements generate a new stacking
context, starting with a z-index value
of 0. Therefore z-index doesn't work
correctly.
See
Bug Report: Explorer z-index bug
and
Squish the Internet Explorer Z-Index Bug
$(function() {
var zIndexNumber = 1000;
$('div').each(function() {
$(this).css('zIndex', zIndexNumber);
zIndexNumber -= 10;
});
});
Use the above if already using jQuery. Details here: http://www.vancelucas.com/blog/fixing-ie7-z-index-issues-with-jquery/
I've found a helpful resource to address this:
Long story short, if your absolutely placed element is empty, IE doesn't like to place it in front of other elements (eg. relatively placed text). You can use a 1x1 transparent gif to overcome this, eg. by setting a style like the following on your absolutely placed element.
.mask {
background: transparent url('/images/clear.gif') repeat 0 0;
}
Related
Please see the screenshot below. I have a jQuery menu and an iframe that loads a PDF document. In Chrome and Firefox this works perfectly and the menu appears over the top of the iframe. I have a z-index: 2 on the menu and a z-index: -1 on the iframe.
Any ideas of how to fix this in IE?
EDIT: jsFiddle
http://jsfiddle.net/hkA2v/1/
Try adding position:relative; on iframe.
iframe{
position: relative;
}
Not directly related to this specific issue.
But people, who are struggling with z-index similar issues in IE9 might consider adding a transparent background in some cases.
Because in IE the element with a link must have a background in order to be click-able. Otherwise the mouse ‘sees right through it’.
background: url(transparent.gif);
Source: Forum Post
Make sure all elements with z-index are siblings of the same parent. If you start nesting elements inside elements and apply new z-index properties to those children, the z-index will start from the parent's z-index, not any z-index properties set before the parent.
IE is very picky with z-index.
Here's a JSFiddle that breaks uniquely in Internet Explorer 9. I'm hoping someone has seen this and knows how to resolve it.
http://fiddle.jshell.net/se9Kc/1/
Note that the scroll area top edge decoration, or "fader", gets clipped on the right side in IE9.
I understand it's natural to question the use of "fixed" at this point. The full page has an inset scrolling table with an absolutely-positioned header, adjacent to the search criteria. The "fader" is anchored to its non-scrolled (but still fluidly-generated) origin with position: fixed.
The defective algorithm seems to go like this:
correctly generate the visibility mask and content for the fixed element
correctly position the element content as requested
incorrectly position the element visibility mask against the left edge
Help?
After doing a bit of testing, it seems like using javascript to handle that particular css property allows it to function properly.
Remove:
position: fixed;
and add somewhere on your page:
<script>
$(.fadeTopGradient).css({'position':'fixed'})
</script>
If you would like accomplish this with css alone, I'm not 100% sure what to tell you. Though I did see a question regarding position:fixed in IE9 asked before here: position:fixed breaks in IE9
I hope this helps.
I have created a page with a "back" button at the bottom right. It looks well positioned in Firefox and more modern browsers however in Internet Explorer 6 the "back" button is missing.
http://www.aetnamarketingcommunications.com/DentalQuiz/QuizTestPage.html
I have tried adding z-index property to this absolute positioned image button without success...what could be the issue?
Thanks, Attila
To fix this bug, try clearing your absolutely positioned element by adding clear: both to the anchor styling. It's a bug in IE6, and has nothing to do with floats.
IE6 is below 1% usage, not sure why you want to support it.
Special Note About Z-Index (IE): If you're using z-index in IE6-IE8, it should be noted that the stacking order in IE gets reset whenever you apply position: absolute, so the z-index is not relative to any of its parent containers.
I don't test for ie6 anymore but I would try *zoom:1 ing everything like so
* {
*zoom: 1;
}
and narrow it down from there..
As per the title, it seems only Chrome isn't playign along. Note that form fields cannot be clicked on which are on the left portion of the screen. This only occurs on some pages (such as the Contact page). It appears that the #left_outer div is overlaying the content. When I edit the css via Firebug or Chrome's dev toools, it works, when I edit the actual css and refresh, it does not.
Any ideas?
LINK:
Thanks!
Usually when you have set the z-index property, but things aren't working as you might expect, it is related to the position attribute.
In order for z-index to work properly, the element needs to be "positioned". This means that it must have the position attribute set to one of absolute, relative, or fixed.
Note that your element will also be positioned relative to the first ancestor that is positioned if you use position: absolute and top, left, right, bottom, etc.
Without a link to look at, it's a bit tough to see what the problem might be.
Do you have a z-index: -1; anywhere (a negative number is the key here, doesn't matter the number)?
I have found in the past this renders the container void from being interacted with.
Good luck!
Markt's answer (see first answer) is great and this is the "by definition" of the z-index property.
Chrome's specific issue are usually related to the overflow property from the top container bottom.
So, for the following:
<div class="first-container">...</div>
<div class="second-container">
<div ...>
<div class="fixed-div> some text</div>
<... /div>
</div>
And styles:
.first-container {
position:relative;
z-index: 100;
width: 100%;
height: 10%;
}
.second-container {
position:relative;
z-index: 1000;
width: 100%;
height: 90%;
overflow: auto;
}
.fixed-div {
position: fixed;
z-index: 10000;
height: 110%;
}
the following actually happens (Chrome only, firefox works as expected)
The 'fixed-div' is behind the 'first-container', even though both 'fixed-div' and its container's ('second-container') z-index value is greater than 'first-container'.
The reason for this is Chrome always enforce boundaries within a container that enforces overflow even though one of its successors might have a fixed position.
I guess you can find a twisted logic for that... I can't - since the only reason for using fixed position is to enable 'on-top-of-everything' behavior.
So bug it is...
I had a weird issue with zIndex on Chrome and I kept fiddling with the position attribute to see if anything worked. But, it didn't. Turns out, in my case, the issue was with the transform attribute. So, if you have a transform attribute in place, disable it and it should be fine. Other browsers work fine with stuff like that, but Chrome seems to play it differently.
Hope this helped you.
Google Chrome to 84.0.4147.135 (Official Build) (64-bit) 2020-02-22.
Since my last update, CSS element z-index is broken in Chrome.
Chrome added "z-index: 1;" to the BODY element.
It now wrongly displays all z-index: ?; values in the BODY child elements.
Setting the position, z-index of BODY does not solve the problem.
Changing z-index values of child elements that were already correct does not help.
I hope this issue will be fixed, it is only broken since I updated Chrome.
Chrome 84.0.4147.135 bug on www.eatme.pro/music - screen smaller than 500 px - push play - appearing bottom bar #lblBottomBarLink with z-index 5 is displayed under menu with z-index 2
(see image)
image eatme.pro/music in Chrome 84.0.4147.135 with z-index 5 under z-index 2
I know this is now resolved but posted solution didn't work for me. Here is what resolved my problem:
<act:AutoCompleteExtender ID="ace" runat="server" OnClientShown="clientShown">
</act:AutoCompleteExtender>
<script language="javascript" type="text/javascript">
function clientShown(ctl, args) {
ctl._completionListElement.style.zIndex = 99999;
}
</script>
javascript snippet:
var ele = document.getElementById( "somelement" );
ele.style.zIndex = 15;
Basically i want to know does firefox and opera support .style.zIndex attribue? b/c i test the above in my code and the zIndex does not seem to reflect..
Take a look at http://fiddle.jshell.net/KdAYc/1/
Also, as other's might suggest, the element that is being given a specified z-index will need to be positioned with either fixed, absolute, or relative. Default is usually static.
Firefox certainly does - not sure about Opera. It may be that some other CSS property is conflicting with the element on which you're setting .style.zIndex - for example, I have seen problems occur when trying to place an element 'on top of' another element that has position: relative. Do you have example code that you can post?
I'm going to go out on a limb here and guess that the elements that you have a z-index for don't have the following css attribute:
position:absolute;
If the positioning is not absolute, it won't work.