webkit-transform overwrites z-index ordering in Chrome 13

Question

Update

Sorry for failing to add the minor detail that we also layer a lot of div elements on top of each other with z-index. After working more with this problem, it seems that the webkit-transform actually messes with the z-index ordering, and that the actual problem is not related to the animations themselves.

End update

I am currently in a project where we develop an application which is quite heavy on CSS3 animations. We're animating a lot of div elements around with -webkit-transform and -webkit-transition.

All is well, until today where all of the to-be-animated elements of the page disappeared. It seems that Google Chrome has updated from 12.xx to 13.0.782.107m and now, all of a sudden, CSS3 properties with -webkit prefixes has stopped working, and elements which have this property applied to them just doesn't show anymore. Removing the -webkit-transform property through the Chrome debugger makes the elements visible again.

Has anyone else experienced the same issues, or know how to solve this problem?

I might add that I've tried to remove just the -webkit prefixes (leaving just transform), which then shows the missing elements, but then that won't animate the elements at all, as the CSS3 property transform is not supported.

I have also tried using el.style.webkitTransform and el.style.WebkitTransform, with no success.

Will pass some example code to explain. The desired result of this is to move sq1 away and reveal sq2.

HTML:
<div id="sq1" style="z-index:10;">
<div id="sq2" style="z-index:5;">

JS
/* fetch the element */
var el = document.getElementById("sq1");
/* apply CSS */
el.style["-webkit-transition"] = "-webkit-transform 500ms linear";
el.style["-webkit-transform"] = "translate3d(30px, 30px, 0px)";

Semmes

I know this question is old, but if anyone finds this, z-index is about the CSS stacking order, and transform is about transforming an element in 3D space, which are unrelated concepts. – Maharajah

Answer 1

Solved it myself through trial and error. Thought I'd report back if someone else stumbles upon this problem. It shall still be noted that this problem did not occur before Chrome updated itself to Chrome 13 (13.0.782.107m).

The trick here seems to be to add a translate3d operation to the underlying <div> (sq2) element upon declaration (or atleast before animating sq1).

Otherwise, the translate3d operation on the overlying <div> (sq1) will cause rendering to ignore the z-index and place sq1 below sq2. I'm guessing that this is because sq1 is defined before sq2 in the DOM, therefore sq2 will be rendered above it.

So, the solution seems to be to put translate3d in the definition of the <div>:s (add it to both just to be clear):

HTML:
<div id="sq1" style="z-index:10; -webkit-transform: translate3d(0px, 0px, 0px);">
<div id="sq2" style="z-index:5; -webkit-transform: translate3d(0px, 0px, 0px);">

Semmes

Legend - this just fixed a similar, annoying bug I was facing. Thanks! – Overfeed

Thank you so much! - this really helped me fix a zindex issue I had with photoswipe on android – Incipit

No idea how you figured this out. I've been banging my head for the last two days on a issue which sounds similar but there have been no browser updates. There were three layers stacked on top of each other - L1, L2 & L3. L3 was animated. All worked fine. They we decided to add animation to L2. All hell broke loose. L3, the one with the highest z-index should have been visible, but we saw on L2. Clicks etc were going to L3 as excepted. Only it wasn't visible. We added in identity transform translate3d(0,0,0) to L2' div and things are working fine. Have any pointers for explanation? – Achlorhydria

I have an issue where transform rotateY causes weird z-index behavior. However, the drawing order is correct the click handlers go in the wrong order. More strange, it only affects part of the element. The suggested workound did not work, I had to find a way to stop using rotateY(180deg). – Eczema

Adding translate3d(0, 0, 1px) on the element I want 'in front' works for me. – Destroyer

To this day, whatever bug is happening here is solved with this fix. Chrome 38, had trouble with using Backstretch.js. – Shoreline

Adding translate3d has some drawbacks. Nowadays, the element which has this style applied will be suffering some problems with subpixel hinting or antialiasing or whatever... the text will be blurry :( – Purebred

Thank you for this. Chrome seems to not have this problem anymore, nor does Firefox on the desktop. But mobile FF appears to still erase the zIndex when a -webkit-transform (or just transform) is applied. If you are animating div transforms via javascript, you must set the zIndex on the div after the transform is applied. – Codger

Answer 2

This should only affect any elements which are positioned as absolute or relative. In order to remedy the issue, you can apply the following css statement to every element which is positioned this way and is causing issues:

-webkit-transform: translate3d(0,0,0);

This will apply the transform to the element without actually doing a transformation, but affecting it's render order so it is above the element causing the issue.

Pucker

Thanks so much for this trick. I had a problem with some CSS styling used to create a circle 'flashing' a square while an icon was spinning. adding this to my css fixed it. – Skyeskyhigh

Answer 3

I think you need to try using -webkit-transform or webkitTransform instead of webkit-transform.

Gastrulation

Answer 4

Use el.style.WebkitTransform (uppercase W).

Segura

Already tried that as well, sorry for not putting both webkitTransform and WebkitTransform in the question. – Semmes

Answer 5

 el.style["-webkit-transition"] = "-webkit-transform 500ms linear";
 el.style["webkit-transform"] = "translate3d(30px, 30px, 0px)";

Your missing the - on the second line, this could be the problem.

Ahvenanmaa