Effect of z-index value to RP and AP blocks

1. Starting setup
2. Apply z-index:1 to AP1
3. Apply z-index to both AP blocks
4. Apply z-index:11 to RP1
5. Apply z-index:21 to RP1
6. Apply higher z-index to RP2 than to RP1, but identical z-index to AP1 and AP2
7. Apply z-index where RP2 > RP1, and AP2 < AP1, both being higher then any RP's
8. Conclusion

In the light of the previous discussion, if I apply z-index:1 to AP1, it will still have to stay below RP2 box. That value of 1 is z-axis position of AP1 inside of the RP1 context. The highest possible value of anything inside of RP1 should still be rendered below the lowest possible value of anything inside of RP2 context.

Amazingly enough, Internet Explorers (both Win and Mac) are the only browsers that do this properly!

• All other browsers (Gecko, KHTML and Opera) violate the spec. They render AP1 above anything inside of RP2, including AP2 because it has default z-index, which is auto.

Why they do this? Why browsers that boasts with standard-compliance all violate the spec in the same manner?

• KHTML browsers (OmniWeb, Safari and quite possibly Konqueror) further violate this wrong implementation, in the case of AP2 having z-index:auto; in that case, AP1 will be above all non-positioned content inside of RP2, but below any AP elements inside of RP2, no matter what z-index value AP1 has.
  If AP2 has defined z-index, then KHTML browsers render as "expected" (AP with higher z-index is above, see next page)

When I first encountered this, I thought that I must have read the spec wrong. But after many re-reads, I can only conclude that IE is the one that does this correct.
So the question remains, why modern browsers do this?

Quite simply, speaking from extensive practical work on CSS2 layouts, they do this because it makes sense.
For instance, if I have multi-level menu where each item is RP (for easy positioning of its submenu):

You would want that Products submenu pops-up above Contact and Help items - give it z-index:10000 and you are ok, right? Well, according to standard, no; no matter what z-index is, that submenu must reside inside of the Products stacking context, which means it should appear below the following RP contexts (for Contact and Help).
There are many situations where standard-compliant behavior creates big problems. One such situation is driving me crazy these days - it was the very thing that drove me to write all this, as I was trying to clear this up for me, looking for solution.

It's a sad irony that the one thing IE implements correctly makes it harder to do such effective things. I would say that CSS spec writers went for logical, but much less practical model (not for the first time).

Continue to next page >>

RP = relatively positioned element
AP = absolutely positioned element