Writing
position: fixed Stopped Working Because a Parent Had an Entry Animation
A decorative slide-up animation left an identity transform on an ancestor, which made it the containing block for everything fixed inside it.
Writing
A decorative slide-up animation left an identity transform on an ancestor, which made it the containing block for everything fixed inside it.
Notes
On 16 September 2026 a full screen editor opened and the panel was not there. Not misplaced. Not behind something. The element existed, the CSS was what I wrote, and in Chrome reported exactly the values I expected.
The element had . It was being positioned against a parent instead of the viewport.
MDN states the condition for fixed positioning: the element is positioned relative to the viewport, unless an ancestor has , or set to something other than . That ancestor becomes the containing block instead. A does the same thing.
Everyone who has hit this knows that list. What got me is that I did not have a transform anywhere. I had an animation:
A section slid up slightly when the page loaded. That is a transform animation, so during those 400 milliseconds the ancestor is a containing block. Fine, I could live with that.
But it does not end when the animation ends. The final keyframe set , and is a transform, not . It computes to an identity matrix, which is still a value other than . With as the fill mode that final value stays applied for the life of the page. So a decorative entry animation that finished before anyone could click anything left the section permanently acting as the containing block for everything fixed inside it.
Computed style tells you , which is true and useless. It is 0px from the containing block. The element really is at the top of its containing block, and the containing block is not the viewport.
is where the disagreement becomes visible: the rectangle you get back is not at the top of the screen. In my case computed read 0px while the rectangle started where the parent section did. When those two disagree, stop reading the element's own styles and start walking up its ancestors.
I stopped trying to fix it with positioning. For anything that must cover the viewport, the element gets moved to the body when it opens and put back where it came from when it closes. on open, restore on close. It removes the whole class of problem rather than one instance of it, and it survives the next person adding an animation to a wrapper three levels up.
A visual effect in one place changes the coordinate system in another place, with no error and no obvious link between the two. If you are looking at an element whose computed position is correct and whose real position is not, the answer is almost never in that element. Check the ancestors for , , , and , and remember that an animation counts as one of them, including after it has finished.
More