CSS: position:fixed inside of 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.

回答1:

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>

回答2:

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.

回答3:

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.

回答4:

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.

回答5:

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.