So this is a bit of a spec oddity. It seems like the transform is forcing a stacking context here, but for some reason in Chrome the z-index of this stacking context is not getting assigned -- the z-index is left at 0. You can see this by running this in DevTools console:
I think this is a bug in Chrome, where it's short-circuiting the new stacking context when a transform is specified, and not propagating the z-index to the new stacking context. The CSS spec says ( https://www.w3.org/TR/css-transforms-1/ ):
> If an element with a transform is positioned, the z-index property applies as described in [CSS2], except that auto is treated as 0 since a new stacking context is always created.
This element is positioned, so z-index should be affecting it.
You can fix it by moving the transform to the child here, but it requires a bit of finagling. Nice catch!
Perfect example of how Chrome is the new IE. When something behaves differently in FF and Chrome, I presume Chrome is wrong until I can prove it otherwise.
>>> getComputedStyle(document.getElementById('prev')).zIndex
"0"
I think this is a bug in Chrome, where it's short-circuiting the new stacking context when a transform is specified, and not propagating the z-index to the new stacking context. The CSS spec says ( https://www.w3.org/TR/css-transforms-1/ ):
> If an element with a transform is positioned, the z-index property applies as described in [CSS2], except that auto is treated as 0 since a new stacking context is always created.
This element is positioned, so z-index should be affecting it.
You can fix it by moving the transform to the child here, but it requires a bit of finagling. Nice catch!