CSS3 Transform has random z-index/depth

Question

Perhaps I have found a Bug in CSS3, or it's a simple mistake...

Here is the page I'm working on: http://robocup2014.herokuapp.com/views/view/52e9bbb2e22d2402003d1ef1

I might not be able to show the error, because its behavior is completely random... But here is what happens:

The flag should be ALWAYS behind that purple layout. However, it is sometimes on top, sometimes below. Sometimes it is on top and goes below (without any code running on javascript), or perhaps it goes on top, out of the blue. Sometimes when it animates, it is below, and then goes on top on the end of the animation, but later, it goes below.

What I mean is: It's RANDOM, and it's a boring bug, without any pattern. (I have counted time, counted animations iterations...).

So, does anyone know how to prevent this? Here is a image, in case in your window it doesn't bug. (It happens on Safari and Chrome)

Answer 1

I had to figure out the same problem recently and the transform: translate3d(0,0,0); solution didn't worked for me.

The fact is that z-index just stack elements in a 2D world, so since you use 3D transformations z-index cannot apply.

So the real question is IMHO :

How to stack elements in a 3D world ?

Answer :

Use the Z axis !

This is simple as it, but not intuitive because of browser's rendering. I made a JSFiddle to try to illustrate it. I tried to match as much as possible to your situation, which is hard, just by having your code through your page. In this fiddle, you have four (2 on 2 lines) flags like. I made 2 other div (score) representing an element that should be over the others. The first line is buggy, while the second isn't.

To see the bug, you can simply move your cursor over an element, knowing that cursor is css pointer on the flag, and css col-resize . You can see that when you hover the green element from left to right, your cursor changes.

I made some schemas (yes, they are ugly ;)) to illustrate the problem. Here are our elements represented as they should be (to my mind) by the browser :

I think the problem is now easier to see. On the right, the green element in over the blue, this is what we want. But, on the left, the rotateY() caused the blue element to "go out of the screen", passing over the green element. See this view "from above" if this is not really clear :

We can think that the blue element go out of the screen by half of its size. So, the solution I found (I think this is probably NOT the best solution, but this work, and is cross-browser since you use browser's own implementations of transform , such as -webkit-transform .

Scroll to the second line of the fiddle, hover the green element, and see that the cursor stays the same BUT we lose totally the cursor pointer over the blue element. I "just" translated the blue element on the Z axis to -10000px, to be sure that it is far away and wont "go out of the screen" when it will rotate. Note the order which is important here, first the translation translate3d(0, 0, -10000px) , then the perspective and finally the rotation giving it : transform: translate3d(0, 0, -10000px) perspective(1200px) rotateY(-45deg); . As you can see on my last schema (from above) :

The blue element is now far away, and wont go over the green one. The last problem we can see , is that if the blue element is larger than 10000 pixels, it will go over the green element again.

In conclusion, I am sure this solution is more a workaround than a real solution. But it was usefull in my case, and I hope I wont fall away from your initial problem and this will help you.

Answer 2

Can you share the browser versions with us? I'm not seeing it on the most recent versions of Chrome or Safari or Firefox.

It might be related to this bug: https://bugs.webkit.org/show_bug.cgi?id=61824

You could try adding this to the flat items:

transform: translate3d(0,0,0);

That way they will all be treated at 3D elements and fewer chances of seeing a bug.

Also, you should be using all the browser prefixes. I'm not seeing the transform on Firefox at all, so I can't tell if it is an issue on that browser, as well.

Answer 3

I can't reproduce the bug in Chrome, Safari or Firefox. I have found a similar question in stackoverflow that may apply to your case ( Complex Webkit Bug? Relative Position + Z-Index + Overflow Hidden + CSS3 Transform )

I would suggest though to use some Javascript before firing the sliding event in order to calculate z-index and apply a higher value on the "purple blocks" or even discard CSS transitions at all and use Javascript transitions only.