2

On webkit nightly builds and chrome canary, every element with position fixed seems to be getting a super high z-index value regardless of what it's given either inline or in the CSS file.

See http://nick-evans.com for an example.

Do you think this a bug in these beta builds, or something incorrect in my code?

The only cause I can think of in my example is that the lower elements are rendered after the page loads using jQuery tmpl (this was an attempt at pseudo lazy loading).

.horizontal-carousel has an explicit z-index set to 1 and is set to position:fixed, meanwhile .col is set to z-index:9 yet all but the contents of the first section element have this relationship in reverse, so the images in the carousel cover their descriptions.

UPDATE

It occured to me that unminified code would help. Here's a link

http://nick-evans.com/clients/me/tsch-tmpl/index.html

Nicholas Evans
  • 2,194
  • 2
  • 16
  • 18
  • Which are the elements that are fixed and _don't_ have a z-index applied explicitly in the CSS? You do have `z-index: 9999` appearing a few times in your CSS. – Matthew Jul 27 '11 at 22:54
  • `.horizontal-carousel` has an explicit z-index set to 1 and is set to `position:fixed`, meanwhile `.col` is set to `z-index:9` yet all but the contents of the first section element have this relationship in reverse. I've added this comment to the above question as an update – Nicholas Evans Jul 27 '11 at 23:03

3 Answers3

5

It's caused by the CSS 3D Transform you added to .horizontal-carousel. In fact, it appears someone has run into a similar problem with that before in "css z-index lost after webkit transform translate3d".

Whether it is your fault or theirs, I'm not sure. The only thing I can find in the spec that looks related to this is:

Any value other than ‘none’ for the transform results in the creation of both a stacking context and a containing block. The object acts as though position: relative has been specified, but also acts as a containing block for fixed positioned descendants. The position on the Z axis of a transformed element does not affect the order within a stacking context. With elements at the same z-index, objects are drawn in order of increasing z position.

The easiest way to fix it is by changing the z value of the translate3d to -1px. But then it doesn't look like you're actually using the transforms at all, at the moment. I don't know if that'll work if you actually start doing something with these transforms.

Fiddling with the z-index of both the element with the transform and its parent might also help, but will probably require some other changes.

Community
  • 1
  • 1
mercator
  • 28,290
  • 8
  • 63
  • 72
  • That's exactly what it was. Great find thanks. Just for the record, the translate3d value is there to invoke hardware acceleration, as described by Thomas Fuchs http://mir.aculo.us/2010/06/04/making-an-ipad-html5-app-making-it-really-fast/ – Nicholas Evans Jul 28 '11 at 14:08
  • As far as I can tell, that just makes the *translation* hardware accelerated. So that would only help if you're actually using it to move stuff. Are you? – mercator Jul 28 '11 at 15:33
  • I am ... sort of. I'm using `-webkit-transition: margin 0.3s linear;` and a change of the margin value to move these elements around. Strictly speaking this isn't a translation I suppose, but it does bring a marked performance enhancement believe it or not. See Remy sharp doing the same thing here http://www.youtube.com/watch?v=IKl78ZgJzm4 and Paul Irish elaborating on the same clip here http://www.youtube.com/watch?v=q_O9_C2ZjoA (skip to 12mins in on the latter). As Paul says, it's a total hack, but it works. Thanks for following up! – Nicholas Evans Jul 28 '11 at 16:49
  • Thanks for those video links... Interesting. – mercator Jul 28 '11 at 17:36
0

I count these elements that have position: fixed on the page:

  • .head (1 header element) is set to z-index 9999 on line 273

  • .static-title (4 h1 elements) is set to z-index 99 on line 388

  • .no-touch .horizontal-carousel (4 div elements) is set to z-index 1 on line 489

All of these elements report the z-index assigned them in the style sheet in the latest Webkit nightly (Version 5.0.5 (6533.21.1, r91865))

steveax
  • 17,527
  • 6
  • 44
  • 59
0

Mercator seems to have it right on, although I experienced something a little different. My page elements all have 3d transforms and when my Disqus dialog box popped up to sign in before posting a comment... the mouse was not interacting with that layer (even though it was being rendered above the 3d transformed layers). What was interesting is that the dialog box with a fixed position was not a descendent of the containers with the 3d transforms.

I had this markup:

<body>
    <div class="book">
        <div class="page">
            <div class="front-side">stuff</div>
            <div class="back-side">other stuff</div>
        </div>
    </div>
    <div id="disqus-dialog">dialog stuff</div>

With the .book container with a perspective and 3d tranforms on the .page, .front-side, .back-side elements. (I'm using dice.js to load my CSS from json) 

'.front-side' : {transitionAll:'400ms', padding_bottom:'150px', position:'absolute', width:'100%', _webkit_backface_visibility: 'hidden', _webkit_transform: 'translate3D(0,0,1px) rotateY(360deg)'},
'.back-side' : {transitionAll:'400ms',  padding_bottom:'150px', opacity:'0', position:'absolute', _webkit_transform: 'translate3D(0,0,-1px) rotateY(180deg)', width:'100%', _webkit_backface_visibility: 'hidden'},

But notice I have the translate3D(0,0,1px) and translate3D(0,0,-1px) and I was unable to interact with my fixed position dialog.

I changed the translate3D styling to this :

'translate3D(0,0,-1px) rotateY(360deg)' 'translate3D(0,0,-2px) rotateY(180deg)'

...and voila! My dialog was now responding to mouse events, but of course now I can't interact with the 3d transformed elements.... what gives?

Strange business, but way worth the effort to fix this. 3d Transforms rock socks... my working site can be seen here with the disqus plugin -> highdensitygames.com

John David Five
  • 811
  • 11
  • 15