z-indexvalue to RP and AP blocks
z-indexto both AP blocks
z-indexto RP2 than to RP1, but identical
z-indexto AP1 and AP2
z-indexto RP2 than to RP1, and higher
z-indexto AP1 and AP1, both being higher then any RP's
So, what to conclude?
IE is right but harder to use in real-world design. All others are wrong but easier to use (but not entirely easier due to implementation bugs).
I hope that these examples will prove to be useful when you are resolving the problems at hand.
And now, a bit of a rant...
Let me first try to build on top of what we already have.
We take the model that works as standard specifies/IE does plus another value for
position property that will render the element above anything else. E.g.
fixed is the value of such sort, only the element with
supreme would not be nailed to its initial position. And it would also go above
Supreme elements would reside in a space of their own, above everything else. Further, if you apply
z-index to them too, you can move them back/front, as needed, while they still stay above anything non-supreme.
That's even more complicated, and it's due to have multitude of implementation bugs!
CSS2 was never fully implemented partly due to its complexity (that's why they built 2.1). The proposal above would be even more complex than what we have now - and it is obvious that implementation bugs still exists in the two-months old browsers.
Hence the simpler positioning model is needed:
The second rule means that ball is tossed to us, web developers, which is more than fine by me. If I have RP element with
z-index 10, and I set its child AP element to have
z-index:5, it would be below its parent. So what? I did that, it's reasonable to think that I know what I do.
If I don't, I should change my profession.
I'm positive I'm missing some issue here. After all, I'm not a spec writer, I'm only trying to earn my living. So I write and complain about the things that trouble me on that path.
And if I'm wrong about anything said on these pages, please let me know.