I'm having issues with IE8 and hope that someone can point me in the right direction.
So I have a parent which is relatively positioned. The parent has two children of which one is absolute and one relative in position. When you hover over the parent, the left values of the children change and the relatively positioned one is supposed to overflow and be hidden.
Here's a fiddle: http://jsfiddle.net/Sladkoff/s7ub9zL8/3/
"Normal" Browsers hide the relative child if it overflows but IE8 will still display it no matter what.
I'm not quite sure if anyone will be able to test this in IE8 thought, since I had to open http://jsfiddle.net/draft/ to see it there. Don't know how this works for guests viewing the fiddle. I guess you need to have it open in e.g. Chrome and then switch to the mentioned link in IE. Let me know if it works...
Any Advice?
Thank you.
Try to use z-index to position your objects in the stacking order you need.
.absolute {
z-index:1;
}
.relative {
z-index:2;
}
Related
Code pen showcasing problem.
https://s.codepen.io/NoMan2000/debug/rdPEYJ/xnrabdnqJadA
I apologize for the rather gnarly HTML, but this is output from a next.js project so the bloated mess is part and parcel of that.
Anyway, the problem can be seen in the element #header-menu-buttonList. The idea is pretty simple, a menu that goes underneath the main grid element. But for whatever reason, it just sits there on the page.
You can pick it up in the debug tools and see that it has a width and a height. Messing with its z-index doesn't make the object visible, only removing the position: absolute makes it visible on the page, but that opens up a whole host of other issues.
So, anyone know:
1.) Why the heck it's doing that?
2.) How to either fix it or work around it?
Thanks for the rubber-ducking. :)
So the issue is that the parent element is positioned absolutely, and the child element is positioned absolutely. I'm not up to snuff on all my CSS rules, but this appears to keep it in the DOM but not render it visible.
The solution is to set the child #header-menu-buttonList to position: static and the parent #header-menu-button to position:absolute.
I'm running into some extremely strange behaviors, and non-consistant across every browser i've tested.
I've a pretty complex layout, but the main issue lies here:
<div id="drop">
<div id="header"></div>
</div>
#drop has position:absolute and z-index:100
#header has position:fixed; top:60px;
As I start scrolling down Chrome ignores the position:fixed rule. If I remove either of the two styles above from #drop then Chrome starts respecting the position:fixed rule.
can't get it working on Ubuntu Chrome 23.0.1271.97 and see the same behavior on Mac Chrome 25.0.1364.99. My friend uses Ubuntu Chrome 25.0.1364.68 beta and it works correctly for him. I've tested it on firefox and it kinda works (with other symptoms)
Has anyone heard of this error? or can anyone even reproduce it?
edit
I'm using openlayers map as another div with position:fixed if I delete that layer or at least change it to display:none then this weird bug goes away.
edit
Noticed that during the presence of this bug, if I change the zoom level back and forth, then the position adjusts itself to the proper behavior. To me, this indicates a webkit issue that fails to execute some internal callback function on scroll.
Another extremely strange thing is that I have a few links inside of #header and they work if I just click the expected location, even though the the div does not appear there. Overall I've noticed that it's only the rendering that's broken. If at any point of time I force the browser to re-render by resizing the window, or changing zoom, or just doing Select-All, then the header bar jumps to the proper position, but does not remain fixed.
You mentioned in the comments that OpenLayers uses CSS transforms. That being the case:
the element with fixed positioning will become relative to the element with the transform - not relative to the viewport
Take a look at the spec: The Transform Rendering Model
Specifying a value other than ‘none’ for the ‘transform’ property
establishes a new local coordinate system at the element that it is
applied to.
.wpr
{
width: 200px;
height:1000px;
background: pink;
position:relative;
margin: 0 200px;
-webkit-transform: translateX(0);
transform: translateX(0);
}
.fixed
{
width: 200px;
height:200px;
margin: 50px;
position: fixed;
top:0;
left:0;
background: aqua;
}
<div class="wpr">
<div class="fixed"></div>
</div>
As the accepted answer says, this is the intended behavior, and is spec-compliant. Another important component of this is what it means to be using CSS transforms.
In your case, it was due to OpenLayers, but this applies to anyone using will-change: transform as well (probably a lot of the people visiting this question). This has been brought up on the Chromium bug tracker here, and marked as WontFix, because (as I said) it's intended behavior. The official comment is this:
This behavior is required by the spec
(http://dev.w3.org/csswg/css-will-change/): "If any non-initial value
of a property would cause the element to generate a containing block
for fixed-position elements, specifying that property in will-change
must cause the element to generate a containing block for
fixed-position elements."
The idea is that once will-change:transform is specified, you should
be able to add/remove/change transforms cheaply, without needing
fixed-position descendants to get re-layed-out.
Note that using other values of will-change (e.g. opacity, top) will
not change the positioning of fixed-position descendants.
As far as I am aware, the only solution is to make the child of the will-change element a sibling instead, to prevent the attribute from cascading.
As a side note, in my specific case, I was able to fix it by being more specific with the will-change attribute. Instead of using it on the div containing the performance-jarring element that required GPU offloading, I used it directly on the offending element. This was due to my original bad code, though, so it won't work for most cases.
You will have to place header outside the parent container drop to make it work.
I had slightly similar issues days back.For instance,if you set z-index of header,it will be attain the z-index of the parent dropcontainer.The z-index of header will be useless because it is already inside a container which has another z-index.
The same logic of z-index applies to position.
I want to add another possible solution because I was struggling with chrome ignoring position:fixed for quite some time until I finally found the culprit:
-webkit-perspective: 1000;
It was coming from a plugin I was using and causes ALL position:fixed elements to be ignored.
Hope it helps someone.
I think this is impossible, i don't think if two positions can be placed at the same place without one to collapse. But i think its better to use Avail height in javascript, i mean if you wanna an outer div to hold inner div, and outer div must cover the whole screen, use Availheight in js, this will get the screen height and then apply if, thereafter set all the divs in fixed position.
Add this to parent:
position: fixed;
...and this to the child:
position: sticky;
First of all, put something in your div as empty ones behave really weird. Then, what do you expect by putting a fixed into an absolute? Obviously, nobody knows what is the reference point of your fixed div. Should it be its parents position? which is not changing with scroll or the page position which changes? Try to use things that are completely meaningful and have a clear definition because if you fix it in chrome, what would happen with another browser? Do you really prefer to test is on all of them?
I suppose a small change in your divs so that pull the fixed div out of the absolute one or move the absolute div somewhere else.
I am building a design and have it pretty much done however an item I have positioned absolutely will not show the overflow in IE7. It works for every browser but IE7.. I'm not supporting ie6. The div/image will not show anything past its parent container in IE7. I've tried a higher z-index, overflow:visible with no success.. The absolute positioned div is in the top nav bar left of the first menu item.. should be obvious
The site is here
thanks for any help or suggestions
To fix it in IE7, do the following:
Remove:
position: relative;
From .navbar-inner
It's a bit redundant to have it on inner, because it's container is already set to a relative position (they are the same size/shape). It will carry the same effect without it on the inner div, and give you the results you're looking for.
Try giving .navbar-inner a higher z-index value than you have given to the absolutely positioned DIV.
I'd reduce your absolutely positioned elements z-index down to something like 100 and make .navbar-inner 101.
I have an HTML code with an error at some point that I cannot detect. Here is my JSFiddle.
In particular, when I move on "Show more", an absolute positioned div with highest z-index should be shown on top of everything. However, as you may see the first absolute positioned div is shown under other content.
As provided in answers from similar questions, I already set a z-index value and the position type (absolute or relative) for each container of the div.
Any idea to solve this problem?
Thanks to Ghost Answer comment, I solved the problem.
In other answers I read that one should put an increasing z-index value as well a position:relative to all the containers of a div that one would show on hover. Maybe it isn't always true.
Here is what I did:
I removed all the z-index values and unnecessary positioning (I suppose the latter is not meaningful).
I set z-index:auto to the container of the div that I would to show on hover.
Now the code works fine: this is the updated JSFiddle.
try this css
.offer-info-shops span
position:absolute;
z-index:1000;
JSFIDDLE
Interesting problem.
Change the following z-indices: .offer-content, .offer-content-info-shops{z-index:auto}
.detail-modal-window{z-index:1}
http://jsfiddle.net/gteEg/12/
By doing this, all the elements have their z-indices compared against each other.
The issue you had was because since you assigned a z-index to offer-content, and .offer-content-info-shops, you had created a stack context, meaning that child elements of .offer-content-info such as .detail-modal-window had their z-index compared to its siblings in .offer-content-info-shops.
https://developer.mozilla.org/en-US/docs/CSS/Understanding_z-index
The nav works the same in every browser i've tested on a mac and pc; however, I cant for the life of me figure out why in IE7 the nav is appearing under the content in the main content block. Check out http://obs4.dynapp.net/ to see the problem, it only exist in IE7. Check out the source if your interested in helping out with the problem. I dunno, I've spent hours staring at html/css and cant figure anything out.
http://obs4.dynapp.net/
This is a seriously annoying IE7 bug. It occurs because positioned elements later in the DOM will be given priority over those earlier in the DOM, regardless of z-index status.
This article will explain how to fix it: http://thedesignspace.net/MT2archives/000763.html
Basically, add position and z-index to the least common ancestor. So, if your header and content are both contained in a container, add position and z-index to that container. If they're direct children of the body, add it to the body.
Hope that helps.
z-indexing is weird with IE7. You have position: absolute for your nav. You have position: relative for your content. Yes, z-indexing should work where your position doesn't matter, but IE7 will take that into affect and give you two different "stacks" for z-indexes so absolute and relative positioned elements do not interact with each other. Try giving your nav a position: relative instead and then readjusting your css accordingly.