Un-fixing Fixed Elements with CSS Transforms
Published 13 years, 2 months pastIn the course of experimenting with some new artistic scripts to follow up “Spinning the Web“, I ran across an interesting interaction between positioning and transforms.
Put simply: as per the Introduction of the latest CSS 2D Transforms draft, a transformed element creates a containing block for all its positioned descendants. This occurs in the absence of any explicit positioning of the transformed element.
Let’s walk through that. Say you have a document whose body contains nothing except a position: static (normal-flow) div that contains some absolutely-positioned descendants. The containing block for those positioned elements will be the root element. Nothing unusual or unexpected there.
But then you decide to declare div {transform: rotate(10deg);}. (Or even 0deg, which will have the same result.) Now the div is the containing block for the absolutely-positioned elements that descend from it. It’s as though transforming an element force-adds position: relative. The positioned elements will rotate with their ancestor and be placed according to its containing block — not that of the root element.
Okay, so that’s a little unusual but perhaps not unexpected. I could make arguments both ways, and some of the arguments could get pretty complex. To pick one example, if the transformed element didn’t generate a containing block, how would translate transforms be handled?
Either way, here’s where things got really troublesome for me: a transformed element creates a containing block even for descendants that have been set to position: fixed. In other words, the containing block for a fixed-position descendant of a transformed element is the transformed element, not the viewport. Furthermore, if the transformed element is in the normal flow, it will scroll with the document and the fixed-position descendants will scroll with it. You can see my test case, where the red and blue boxes would overlap each other and stay fixed in place, except the second green div has been rotated.
Obviously this makes the fixed-position elements something less than fixed-position. In effect, not only does the transformed element act as if it’s been force-assigned position: relative, the fixed descendants behave as if they’ve been force-changed to position: absolute.
I find this not only unusual and unexpected, but also a wee bit unsettling. Personally, I think it goes too far. Fixed-position elements should be fixed to the viewport, regardless of the transformation of their ancestors. Of course, if you agree with my thinking there, realize that opens a whole new debate about how, or even whether, transforms of ancestors should be carried to fixed-position descendants.
I have my own intuitions about that, but this is definitely territory where intuitions are to be treated with caution. There are a lot of interacting behaviors no matter what you do, and no matter what you do someone’s going to find the results baffling in some way or other.
But since I do have intuitions, here’s what they are: transformed elements in the normal flow or floated do not establish containing blocks for absolutely- and fixed-position descendants. This means that any transforms you apply to the transformed element are not applied to the positioned descendants, because transforms don’t inherit.
What if you want a normal-flow transformed element to be a containing block? Use position: relative, same as you would if there were no transform. And if you want the transforms to be passed on to the descendants even though no containing block is established? The inherit value would work in some cases, though not all. That’s where my approach runs aground, and I’m not yet sure how to get it back to sea.
Okay, so that’s what I think. What do you think?