10 ms·
So I changed the z-index of Div A to be 5 or something. But it didn’t work! In Firefox, div A was on top, but in Chrome, Div B was on top. Argh! Why? ... why i
by EvilTerran 7y ago
So I changed the z-index of Div A to be 5 or something. But it didn’t work! In Firefox, div A was on top, but in Chrome, Div B was on top. Argh! Why?
... why indeed? I can't think of any (presumably fairly simple) scenario where that would happen.
- jvns 6y agoI got a bit nerdsniped by this so here's a simple reproduction of the original issue (which I still don't fully understand tbh) https://codepen.io/jvns-css-fun/pen/zYGVLXj https://codepen.io/jvns-css-fun/pen/zYGVLXj
- Jasper_ 6y agoSo 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: >>> 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/ 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!
- sgc 6y agoPerfect 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.