z-index quirks
Take a look at this CSS:
and this HTML:
Now, which div is on the top? blue, of course, because it has the highest z-index, right? Wrong. red is on top because .. well, I’ll get to it. But anything inside the wrapper is behind anything before the wrapper, regardless of the z-index.
According the the CSS spec (http://www.w3.org/TR/CSS21/visuren.html#z-index) (and the elaborate appendix (http://www.w3.org/TR/CSS21/zindex.html)), this is the designed behavior:
The contents of inline blocks and inline tables are stacked as if they generated new stacking contexts, except that any elements that actually create new stacking contexts take part in the parent stacking context. They are then painted atomically in the inline stacking level.
Essentially, elements with different parents cannot be intermixed. z-index is only used to order adjacent elements. So, for this example, the renderer says, “red has an index of 2, and wrapper has a default index of 0, so red, and all its children, are in front of wrapper and all its children”.
Aside
This came up when I was working on my raycaster. In my previous version, sprites were handled by inserting img tags using innerHTML. The walls are handled in the same way, and the sprite HTML is just tacked on the the end of the wall HTML. But doing this causes the browser (both IE and Firefox) to send extraneous HTTP requests whenever an image is inserted. My immediate solution was to the use persistant nodes for the sprites and just move them by setting the styles.
Unfortunately, since the code for creating the walls uses the same innerHTML, I had to break the sprites out into a separate part of the structure:
became:
Which, like in the opening example, meant that each sprite would be either in front of every wall, or behind every wall.
The correct solution is to preload the images. By throwing all the images into a div with display: none, they get cached correctly.