Internet explorer z-index issue
Because the divs you're trying to stack are in two different contexts (i.e. they are nested in other divs so they are not sibilings) you're not going to be able to set their z-index directly.
I think you'll have to set the z-index of the parent that is an actual sibling of the other...so since #top and #content-full are sibilings, you can need to set the z-index of #top with a higher number. This also means you'll have to position #top to something other than it's default static.
z-index does not work in Internet Explorer with pdf in iframe
Update: Matthew Wise has a really clever alternative solution which you should consider—especially if you're having trouble with my approach or dislike ugly hacks!
There is a way to cover windowed elements in IE with other elements, but you're not going to like it.
Background: windowed and windowless elements
Legacy IE categorises elements into two types: windowed and windowless.
Regular elements like div and input are windowless. They are rendered by the browser itself in a single MSHTML plane and respect each other's z-order.
Elements rendered outside of MSHTML are windowed; for example, select (rendered by the OS) and ActiveX controls. They respect each other's z-order, but occupy a separate MSHTML plane that is painted on top of all windowless elements.
The only exception is iframe. In IE 5, iframe was a windowed element. This was changed in IE 5.5; it is now a windowless element, but for backwards compatibility reasons it will still draw over windowed elements with a lower z-index
In other words: iframe respects z-index for both windowed and windowless elements. If you position an iframe over a windowed element, any windowless elements positioned over the iframe will be visible!
What this means
The PDF will always be painted on top of the regular page content—like select elements were until IE 7. The fix is to position another iframe between your content and the PDF.
Demo
jsFiddle: http://jsfiddle.net/Jordan/gDuCE/
Code
HTML:
<div id="outer">
<div id="inner">my text that should be on top</div>
<iframe class="cover" src="about:blank"></iframe>
</div>
<iframe id="pdf" src="http://legallo1.free.fr/french/CV_JLG.pdf" width="200" height="200"></iframe>
CSS:
#outer {
position: relative;
left: 150px;
top: 20px;
width: 100px;
z-index: 2;
}
#inner {
background: red;
}
.cover {
border: none;
position: absolute;
top: 0;
left: 0;
height: 100%;
width: 100%;
z-index: -1;
}
#pdf {
position: relative;
z-index: 1;
}
Support
This has been tested and should work in IE 7–9. If you feel persnickety about it showing up in the DOM for other browsers, you can add it with JavaScript or wrap it in an IE-only conditional comment:
<!--[if IE]><iframe class="cover" src="about:blank"></iframe><![endif]-->
Internet explorer z-index issue
Because the divs you're trying to stack are in two different contexts (i.e. they are nested in other divs so they are not sibilings) you're not going to be able to set their z-index directly.
I think you'll have to set the z-index of the parent that is an actual sibling of the other...so since #top and #content-full are sibilings, you can need to set the z-index of #top with a higher number. This also means you'll have to position #top to something other than it's default static.
IE 10 not respecting z-index
Internet-Explorer is very tricky particularly with z-index and positions.
Okay, whats the Solution?
Hard work. Be sure that elements are mostly have an position. Must in some places work with position: relative;.
To address the problem with the z-index, you must go from the highest parent (<html>) up to all childs and set each child a z-index (started with 0), increase each z-index, example:
html {
z-index: 0;
}
body {
z-index: 1;
}
header {
z-index: 2;
}
header nav {
z-index: 3;
}
Generally, check the validity: HTML Validator, CSS Validator
How can I make iframe respect z-index in IE?
Try using Youtubes iframe embed method (if thats not what you are already doing, and add:
?wmode=transparent to the url (replace ? with & if it is not the first url variable)
Firefox and Safari don't respect z-index after 'perspective' change
Ok, I have no experience with this part of css, but it looks, that if you will make small red square and thanks to translate3D, you will position it forward so it has similar size as square behind then it works (Tested on Firefox).
Question is if this solution is fine for you:
https://jsfiddle.net/zdoe56yr/3/
.red {
position: relative;
z-index: 2;
transform: translate3d(0px, 0px, 200px);
margin-top: -15%;
background: red;
width: 75px;
height: 75px;
}
But you still need that z-index for Chrome and IE.
Android Webkit: Absolutely positioned elements don't respect z-index
This problem is probably related to controls and their being special for the browser. While looking at your problem (in chromium) I found a related problem that when you press the tab key you will still be able to focus the input elements. You probably don't want this either (regardless of bleedthrough). The solution is surprisingly simple, you write your script to add the disabled attribute to all input/button/etc. elements that are overlayed. A disabled input will not be able to receive focus (by keyboard or otherwise), and clicking it should be impossible.
As this also disables silly keyboard circumnavigation it is not even a workaround, but a better design that also works with keyboard based navigation as expected.
z-index chrome bug
one800higgins's answer is along the right lines. The real answer is that on mobile WebKit and Chrome 22+, position: fixed always creates a new stacking context, even when z-index is auto. So the stacking context hierarchy looks like this:
- document root (z-index
0)#mask(z-index9998)#box(z-index0).above-mask(z-index9999).below-mask(z-index9997)
That means that 9998 is never compared with 9999 or 9997 to determine stacking order. Instead, 9999 is compared with 9997 to determine which of .above-mask and .below-mask is further in front, and then once everything inside #box is stacked in that context, it's treated as a single layer at z-index 0 which gets stacked behind #mask at z-index 9998.
This also explains why @TheNextBillGates's answer of moving #mask inside #box works - because then #mask is in the same stacking context as .above-mask and .below-mask. I highly recommend the above link for more comprehensive details, and you should also see the announcement for the stacking change for fixed elements in Chrome.
Related Topics
How to Check for Duplicate CSS Rules
How to Use Svg Sprite Sheet as CSS Background-Image While Maintaining Aspect Ratio and Scalability
Pixel Density, Retina Display and Font-Size in CSS
Responsive Images Positioned Over Image
Why Does Grid-Gap Cause an Overflow
Csp Style-Src: 'Unsafe-Inline' - Is It Worth It
Change Icon-Bar (☰) Color in Bootstrap
How to Make a CSS Triangle with Smooth Edges
Display Bootstrap Popovers Outside Divs with Overflow:Hidden
Hovering Over CSS Transition in Safari Lightens Certain Font Color
How to Cut Out a Triangle Section from a Div Using CSS
Font Smoothing Techniques? Text-Shadow Rendering Differently in Chrome 14.0.833.0 or Higher
How to Make a Transparent Border with CSS