测试结果：

在FF3.0中结果和标准顺序一致。FF2.0中“z-index值为负值的定位元素”在父级stacking context的背景下面。（注意ff2.0的这个特殊性）

IE下测试

测试页面：demo02.html (请在IE下浏览)

代码说明：

此代码也是根据上面的测试思想，但由于inline元素在ie中的特殊性，把inline的代码写在了后面，事实证明结论是正确的。对于“block元素”和“float元素”顺序大家可以交换顺序测试。

测试结论：

IE下（无论ie6.0或者ie7.0）“float元素”和“block元素”属同一stack level，而“inline元素”较其stack level低。

解释：

“float元素”，“z-index：auto的定位元素”仿佛产生了新的stacking context，但其真正能产生新的stacking context的后代任按其父级stacking context定位。（但IE中“z-index：auto的定位元素”
会拥有z-index值0，产生一个新的stacking context，并影响其子元素定位。这是IE一个BUG）
inline元素在FF中仿佛能产生新的stacking context，而在IE中则不能。

至此stack level规则内容已经完毕，现在应该能理解stack level和z-index的不同。stack level来决定这一个stacking context中各元素在z轴上的显示顺序，对于同一stack level的定位元素才由z-index进一步决定显示次序。

一些问题的解释

怿飞版主在《z-index在IE中的迷惑》一文中最后提到的问题：

演示地址：demo03.html

认为：

解惑：IE浏览器似乎给body元素默认了一个相对定位属性（position: relative）。

真是这样吗？

演示地址：demo04.html

分析：

box1显示在body的下方，根据上面的stack level规则，IE中，如果body默认了一个位置属性，即body是其父级stacking context，box1应显示在其上方，事实却不是这样。而且当我们给body加上position：relative以后，显示效果和stack level规则一致。所以body并没有默认位置属性。

那为什么负值的定位元素在IE和FF下显示不一致呢？

ie 中根据stack level规则： z-index为负的定位元素的stack level比父级stacking context（此处是root stacking context）高，显示在其上方。故box1在ie中能显示。ff3.0和标准一致，也能显示。大家可以试一下。

ff2.0 中由于那条特殊的stack level，即 z-index为负的定位元素的stack level比父级stacking context（此处是root stacking context）低，所以显示在root stacking context下方。故不能看见。

另外，上面的代码中加上opacity那条后，在ff2.0中即可显示了。这又是什么原因呢？

推测：在火狐中如果给元素设置opacity属性（1除外），即会产生新的stacking context。

上面加上opacity属性后在ff2.0中可显示box1在body下，ff3.0box1在body上，（可以根据上面的stack level规则自己分析）符合推测。
在w3c的说明中也证明这点

引用：

In future levels of CSS, other properties may
    introduce stacking contexts, for example 'opacity'
    [CSS3COLOR].

总结：

在一个stacking context中元素的z-轴显示顺序，由元素所处的 stack level 决定。对于同一stack level的定位元素由z-index的大小进一步决定显示次序。

1. ie中给元素设置position属性（static除外）可产生新的stacking context
2. ff中给元素设置opacity属性（1除外）可产生新的stacking context

除此之外（也许设置其他属性也会产生新的stacking context，但还不知道）只有定位元素设置了z-index(auto除外)才会产生新的stacking context，子元素将按照新的stacking context，定位。