I've come across a strange "bug" on Chrome where the z-index is not showing properly like in every other browser (including IE).
I've read all related questions related to it and almost everyone in their questions were missing position or overflow.
The link for the website is THIS and there is a dropdown ul element in the middle search that when you click it, is behind the pictures. I've tried for hours all possible combinations with child-parent, different z-indexes, positions and nothing seem to get the dropdown in front of the pictures.
I would really appreciate it if someone could point me in the right direction or provide a sample to help me out.
Thanks!
Solution from answers: The div element which had the problem, has around 10 div elements above it as "parents". His z-index could not get in the front because his highest parent did not have position:relative, only had z-index which caused the problem for all other child divs below it.
Here is an example:
<div> <---- had only z-index, was missing position:relative
<div>
<div>
<div> <---- this div with z-index could not get in front because of the first one
</div>
</div>
</div>
</div>
You have to add
z-index: 1000; /* or whatever value works*/
position: relative;
to your #big-map. This will fix it. You forgot to add a position to that div, which makes that a z-index doesn't get applied.
The CSS of #big-map should look like this:
#big-map {
width: 100%;
height: auto;
/* background-color: rgb(229, 227, 223); */
/* background-color: #E0E0E0; */
-webkit-transform: translateZ(0);
display: block;
z-index: 1000;
position: relative;
}
I agree with Toni Leigh though: in the future you need to share code and a working example, so this question is also value in the future. If you can't share code or set up an example with a minimum amount of code, you can always ask it in the chat, where we gladly help you with such "bugs".
This is not a bug. The fact is that z-index must be defined on the parent element as well. Basically, how is an element supposed to act if the child has a higher z-index than the parent?
The problem is on your #big-map which is the parent.
It must have a high z-index, and position relative:
z-index: 10000;
position: relative;
adding that to your #big-map will solve it.
Only solved when the z-index is added to the tag for position absolute and fixed.
<div style="z-index:110">
No matter how high the value is in CSS, chrome bug converts it to a maximum of 17.
z-index:99999999999999999999999999999999;// translates into z-index:17
Related
I am using fixed positions elements along side the css property clip to make a cool scrolling / paging effect.
This all works great but my issue is that I cannot click my links.
I can see that the fixed elements are overlaying each other which is causing the issue but I cannot figure out how to fix it.
I have tried changing z-index values on the containers and the anchor tag with no luck.
Here is a fiddle: http://jsfiddle.net/9ukyrbc0/
If anyone can help that would be amazing!
Cheers!
The problem is within .fixed-container:
.fixed-container {
position: fixed;
top: 0px;
left: 0px;
right: 0px;
bottom: 0px;
-webkit-backface-visibility: hidden;
-moz-backface-visibility: hidden;
backface-visibility: hidden;
pointer-events: none; <-----
}
pointer-events: none;
Pointer Events are not triggered at all within that container ... thus links are not active.
more on this here ...
https://developer.mozilla.org/en-US/docs/Web/CSS/pointer-events
So I have figured it out, but I cannot really explain it.
The first thing to do is to remove pointer-events: none so thanks to #manhatmanich for spotting that one.
This makes the first link clickable but not the rest, it looks like a z-index issue but changing the z-index values does not work.
So while playing around I tried removing the position absolute from the anchor tag and BOOM, all links clickable.
You can see a fiddle here: http://jsfiddle.net/9ukyrbc0/10/
I honestly don't understand how this fixes the problem but it does!
I was having the same issue, the code given here without the pointer-events: none; worked for me. The only issue is that I also had links in my fixed position element and now those links don't work.
For me it was a floating action button with poistion-fixed bootstrap class added that did not work. It worked by just adding z-index:1 to its styles.
This question already has answers here:
Why does applying a CSS-Filter on the parent break the child positioning?
(4 answers)
Closed 1 year ago.
I'm developing a wordpress theme, with an isotope grid and where a hover on a post should display its title with a fixed position on the bottom of the browser. I have this simplified structure:
<div id="main">
<article class="hubbub">
//article content
<h2 class="subtitled">
//h2 content
</h2>
</article>
</div>
Via jQuery, a hover on <article> should display its child element h2.subtitled. <article> is positioned relative, but gets an absolute position by the isotope script. The h2.subtitled is positioned fixed with:
.subtitled {
display: none;
position: fixed;
z-index: 999999999;
bottom: 20px;
left: 0;
width: 100%;
font-family: Arial, Helvetica, sans-serif;
font-size: 42px;
text-align: center;
color: yellow;
}
For some reason, the h2.subtitle elements get positioned fixed related to the parent <article> element, so an the bottom of each <article>. If I set the <h2> outside of the <article>, it is positioned fixed related to the browser, but they need to be inside of the <article> element, because an infinite scroll appends the new <article> elements and they should as well contain the <h2> titles.
Does anyone know, how to make this position fixed and related to the browser window?
Thanks!
FWIW, when I ran into this, the problem turned out to be a parent div with -webkit-transform: translate3d(0, 0, 0) in its CSS. Apparently, this is a known source of potential mayhem in child elements with position: fixed.
For what I was trying to do (turning fixed on and off as a way of sticking a key nav element to the top of the page as it scrolled by), the solution was to append it to the page body element when it was time to hold it in place and sticking it back in its wrapper div when it wasn't. No idea if any of this would have helped the OP, but if you're chasing this bug yourself, worth looking into.
Remove the transform property from the parent of the fixed element.
For some reason this causes the fixed element to become relative to the parent instead of the document.
Codepen example.
In case there are other people who have been running into this mess and don't have a transform property, the value of a properly that has blur() also causes this to mess up.
This was such a pain point for me. Too much time wasted of figuring this one out.
:(
In my case, the parent element doesn't have a transform property but filter: drop-shadow(...) which caused the same problem. Removing the filter solved the problem.
The Goal
I'm practicing writing my own simple JavaScript slideshow plugin, and the intended method is to have all of the images -- all of which are the same size -- in the same location on the screen (so all having the same x and y values), but alter their z-indexes to shuffle them in front of or behind each other as necessary, cycling through each of them. The JavaScript is working well so far, but I'm not able to get the images to all layer on top of each other on the page -- they just stack, from the top of their container downward, one per line.
What I've Got
This is a simplified version of the relevant portion of my HTML:
<section>
<div class="images">
<img src="1">
<img src="2">
<img src="3">
</div>
</section>
And the CSS
.images {
height: 15em;
margin: 0 auto;
overflow: hidden;
width: 20em;
}
As you can see, it's not too complex. I'm at a loss as to where to go from here, though. The only way I've been able to get the images to layer the way I want is to apply position: absolute; and top: 0; to the images, but that also throws them outside of their div, and then applying that to the div itself causes the whole layout to go into chaos. So if anyone has any advice, I'd greatly appreciate it! :)
Add position:relative to your .images class. Absolutely positioned elements are positioned with respect to their closest positioned ancestor element.
You need to apply position: relative to the div. That way the images use their parent div as a reference.
One option would be to use the JavaScript to modify the display and visibility CSS attributes to show and hide the images.
visibility: hidden means the element is not visible, but it still takes up space in the page flow.
display: none means the element takes up no space in the page flow.
I've seen browsers behave oddly when display is none but visibility is hidden. I've found it's best to switch both.
For the image you want to be visible, set display: block and visibility: visible
I have a fixed position element inside a relatively positioned element, as far as I'm concerned the position: relative element shouldn't have any effect on the position: fixed (fixed elements are positioned relative to the window, right?).
However, the fixed elements z-index seems to be inherited by it's parent, to the point where it's z-index can be no higher than its parent's z-index.
I hope I'm making sense? Below is a HTML example of what I'm talking about:
.outer {
position: relative;
z-index: 2;
}
.inner {
background: #fff;
left: 50px;
position: fixed;
top: 40px;
z-index: 1000000;
}
.fade {
background: #555;
bottom: 0;
left: 0;
opacity: 0.5;
position: fixed;
right: 0;
top: 0;
z-index: 3;
}
<div class="outer">
<div class="inner">testing testing</div>
</div>
<div class="fade"></div>
If you change the following:
.outer { position: relative; z-index: 4; }
Then the .inner element appears in front of the fade element.
I find this behaviour very peculiar... is there a way of working around this without moving the .inner div, or changing the CSS of the .outer div?
Fiddles of above code samples:
http://jsfiddle.net/n2Kq5/
http://jsfiddle.net/U8Jem/1/
In short, yes, an element with position:fixed is limited by its parent's z-index given the parent's z-index is defined.
Sad to inform you, but what you want is not currently possible. The only way you can get the effect you desire is to change your HTML or remove the z-index from outer.
Changing HTML options
The first option is to move inner outside of outer, which would look like this.
The second option for an HTML fix is to move fade inside of outer (using the same CSS even) - demo of that here.
A third option would be to put fade inside of outer and then also put inner inside of fade, but that requires you to use rgba colors and opacity - that demo is found here.
Changing CSS options
The closest thing you can get using the same HTML you have currently is to remove the z-index of outer - Demo here. You would think that you could simply increment each element's z-index by two, but that does not work due to the fact that children elements cannot have a higher z-index than their parents (if the parent's z-index is set).
Explanation
If you think about it, fade and outer are on the same level. What you're trying to do is have fade remain on that same level but also have it be on the level above, which is impossible. It's like trying to be on two floors of a building at once, it can't be done.
Although what you need is not directly related to this article, Philip Walton created a great post on z-indexes and the effect opacity has on them, which could be useful to others looking at this question.
I've isolated a little test case of IE7's z-index bug, but don't know how to fix it.
I have been playing with z-index all day long.
What is wrong with z-index in IE7?
Test CSS:
input {
border: 1px solid #000;
}
div {
border: 1px solid #00f;
}
ul {
border: 1px solid #f00;
background-color: #f00;
list-style-type: none;
margin: 0;
padding-left: 0;
z-index: 1000;
}
li {
color: #fff;
list-style-type: none;
padding-left: 0;
margin-left: 0;
}
span.envelope {
position: relative;
}
span.envelope ul {
position: absolute;
top: 20px;
left: 0;
width: 150px;
}
Test HTML:
<form>
<label>Input #1:</label>
<span id="envelope-1" class="envelope">
<input name="my-input-1" id="my-input-1" />
<ul>
<li>item</li>
<li>item</li>
<li>item</li>
<li>item</li>
</ul>
</span>
<br><br>
<label>Input #2:</label>
<span id="envelope-2" class="envelope">
<input name="my-input-2" id="my-input-2" />
</span>
</form>
Z-index is not an absolute measurement. It is possible for an element with z-index: 1000 to be behind an element with z-index: 1 - as long as the respective elements belong to different stacking contexts.
When you specify z-index, you're specifying it relative to other elements in the same stacking context, and although the CSS spec's paragraph on Z-index says a new stacking context is only created for positioned content with a z-index other than auto (meaning your entire document should be a single stacking context), you did construct a positioned span: unfortunately IE7 interprets positioned content without z-index this as a new stacking context.
In short, try adding this CSS:
#envelope-1 {position:relative; z-index:1;}
or redesign the document such that your spans don't have position:relative any longer:
<html>
<head>
<title>Z-Index IE7 Test</title>
<style type="text/css">
ul {
background-color: #f00;
z-index: 1000;
position: absolute;
width: 150px;
}
</style>
</head>
<body>
<div>
<label>Input #1:</label> <input><br>
<ul><li>item<li>item<li>item<li>item</ul>
</div>
<div>
<label>Input #2:</label> <input>
</div>
</body>
</html>
See http://www.brenelz.com/blog/2009/02/03/squish-the-internet-explorer-z-index-bug/ for a similar example of this bug. The reason giving a parent element (envelope-1 in your example) a higher z-index works is because then all children of envelope-1 (including the menu) will overlap all siblings of envelope-1 (specifically, envelope-2).
Although z-index lets you explicitly define how things overlap, even without z-index the layering order is well defined. Finally, IE6 has an additional bug that causes selectboxes and iframes to float on top of everything else.
http://www.vancelucas.com/blog/fixing-ie7-z-index-issues-with-jquery/
$(function() {
var zIndexNumber = 1000;
$('div').each(function() {
$(this).css('zIndex', zIndexNumber);
zIndexNumber -= 10;
});
});
In IE positioned elements generate a new stacking context, starting
with a z-index value of 0. Therefore z-index doesn’t work correctly.
Try give the parent element a higher z-index value (can be even higher than the child’s z-index value itself) to fix the bug.
I encountered this issue, but on a large project where HTML changes had to be requested and became a whole issue, so I was looking for a pure css solution.
By placing position:relative; z-index:-1 on my main body content my header drop down content suddenly displayed above the body content in ie7 (it was already displaying without issue in all other browsers and in ie8+)
The problem with that was then this disabled all hover and click actions on all content in the element with the z-index:-1 so i went to the parent element of the whole page and gave it a position:relative; z-index:1
Which fixed the issue and retained the correct layering functionality.
Feels a bit hacky, but worked as required.
I found that I had to place a special z-index designation on div in a ie7 specific styelsheet:
div { z-index:10; }
For the z-index of unrelated divs, such as a nav, to show above the slider. I could not simply add a z-index to the slider div itself.
If the previously mentioned higher z-indexing in parent nodes wont suit your needs, you can create alternative solution and target it to problematic browsers either by IE conditional comments or using the (more idealistic) feature detection provided by Modernizr.
Quick (and obviously working) test for Modernizr:
Modernizr.addTest('compliantzindex', function(){
var test = document.createElement('div'),
fake = false,
root = document.body || (function () {
fake = true;
return document.documentElement.appendChild(document.createElement('body'));
}());
root.appendChild(test);
test.style.position = 'relative';
var ret = (test.style.zIndex !== 0);
root.removeChild(test);
if (fake) {
document.documentElement.removeChild(root);
}
return ret;
});
It looks like not a ie bug, just for diffrent understanding to the css standard. If outside container is not specified the z-index, but the inner element specified a higher z-index. So the container's sibling maybe overlay the high z-index element. Even if like that, it only occurs in IE7, but IE6, IE8 and Firefox is ok.
In IE6 in general, certain UI-elements are implemented with native controls. These controls are rendered in a completely separate phase (window?) and always appear above any other controls, regardless of z-index. Select-boxes are another such problematic control.
The only way to work-around this issue is to construct content which IE renders as a seperate "window" - i.e. you can place a selectbox over a textbox, or, more usefully, an iframe.
In short, you'll need to put "on-hover" like things such as menu's in an iframe in order to let IE place these above built-in UI controls.
This should have been fixed in IE7 (see http://blogs.msdn.com/ie/archive/2006/01/17/514076.aspx) but perhaps you're running in some kind of compatibility mode?
This bug seems to be somewhat of a separate issue than the standard separate stacking context IE bug. I had a similar issue with multiple stacked inputs (essentially a table with an autocompleter in each row). The only solution I found was to give each cell a decreasing z-index value.
If you wanna create dropdown menu and having a problem with z-index, you can solve it by creating z-indexes of same value (z-index:999; for example).. Just put z-index in parent and child div's and that will solve problem. I solve the problem with that. If i put different z-indexes, sure, it will show my child div over my parent div, but, once i want to move my mouse from menu tab to the sub-menu div (dropdown list), it dissapear... then i put z-indexes of same value and solve the problem..
I solved it by using the developer tools for IE7 (its a toolbar) and adding a negative z-index to the container of the div that will be below that the other div.