CSS3 Translate3d Mouse Events Issue
So, I’ve got this bit of code: jsfiddle.net/XNvzW; webkit only for the brevity of this demo.
The colored blocks are setup in a 3d scene where the colored boxes overlap a bit and have the following z-values: 10, 5, 0, -5, -10 (the numbers in the upper right corners of the boxes). When you hover over a box, the color changes and you’ll see a message saying: hovering over #x.block. Pretty simple.
Now, sometimes the negative z blocks work (and respond to mouse events, both in CSS with :hover and in JS with $.mouseenter()), and sometimes they don’t, it’s seems entirely inconsistent as to when and why, to toggle back and forth between working and not, just reload a few times. There seems to be some sort of issue w/ the negative value of the TranslateZ property, the W3C even uses a negative value in their example of how one would use Z. The one relevant stackoverflow question that I found didn’t seem to get much discussion or an answer solving the issue.
I seem to be able to reliably get the negative values to work if I am moving the mouse as the page is loading, literally: move mouse in circles, hit CTRL/CMD+R
I have also tried getting around all of this by setting everything to be a positive Z-value and adjusting my perspective, but this technique doesn’t seem to augment where the zero-plane of the z-axis is, and I am trying to create some extreme depth with objects far away as well as near by. The positioning works fine, the mouse events are the issue.
Update: jsfiddle.net/XNvzW/32 the blocks seem to act differently when they are unstacked. #e.block is negative and works… and #d.block which is close to #c.block and is negative, doesn’t. Could there be some overlap-like issue?
Update: Found WebKit Bug 42455 - click event not caught by elements after a negative translateZ, unfortunately it looks like it’s still unconfirmed.
Update: Found Chromium Issue 110462: Children of translateZ( z ) are visible, not interact-able, when: perspective - z < 0 which was at least opened and assigned recently, and it seemed to be working in version 16 and currently not in 18. Looks like this might be a legit bug, and not me.
Thanks for the help @taudep.