聲明
定位元素：
position屬性值設置除默認值static以外的元素，包括relative，absolute，fixed。
平台：win/IE win/FF
z-index
用來確定定位元素在垂直於顯示屏方向（以下稱為Z軸）上的層疊順序
值：auto | 整數 | inherit
默認：auto
適用於：定位元素
繼承性：no
理解stacking context
每個box都歸屬於一個stacking context,它是元素在z軸方向上定位的參考。根元素形成 root stacking context，其他stacking context由定位元素設置z-index為非auto時產生。如#div1{position:relative;z-index:0;}即可使 id=div1的元素產生stacking context。stacking context和 containing block 並沒有必然聯系。
理解stack level
在一個stacking context中的每個box，都有一個stack level（即層疊級別，以下統一用stack level），它決定著在同一stacking context中每個box在z軸上的顯示順序。同一stacking context中，stack level值大的顯示在上，stack level值小的顯示在下，同一stack level的遵循後來居上的原則（back-to-front ）。不同stacking context中，元素顯示順序以父級的stacking context的stack level來決定顯示的先後情況。於自身stack level無關。注意stack level和z-index並不是統一概念。（將在後文慢慢理解）
stack level規則
每個stacking context中可包含塊級（block）元素、內聯（行內inline）元素，還有設置float屬性的元素、定位元素等等他們在同一父級 stacking context中的顯示順序是怎樣的？即stack level是怎樣的呢？比如一個塊級元素和內聯元素發生層疊的話誰會在上面呢？是不是誰在後面誰就在上面呢？
根據w3c關於 stack level 的介紹可以得出以下stack level規則
每個stacking context都包括以下stack level （後來居上）：
以上stack level在浏覽器執行情況：
firefox3.0下測試完全吻合，Firefox2.0下稍有不同即：“z-index值為負值的定位元素”在“父級stacking context的背景、邊界”之前。
IE6.0和7.0中：inline元素的stack level位於block元素之前，且“文本流中非定位的、float浮動子元素”（以下簡稱浮動元素）和“文本流中非定位的、block塊級子元素”（以下簡稱block元素）處於同一級。
測試
FF下測試
運行代碼框
[Ctrl+A 全部選擇 提示：你可先修改部分代碼，再按運行]
測試頁面：
http://rong179.blogbus.com/files/12163574750.Html（請分別在FF3.0和FF2.0中打開）
代碼說明：
由前所述，如果元素的stack level同級則後來居上；元素的stack level高，這無論代碼在文檔中位置如何都顯示在上面，即使代碼在最前面；如果元素的stack level低，無論代碼位置如何都將顯示在下面，即使代碼在最後面。
我們就根據這一點，以“3.文本流中非定位的、block塊級子元素”和“4.文本流中非定位的、float浮動子元素”為例，如果我把“float元素” 的代碼寫在“block元素”的前面，且實際顯示為：“float元素”在“block元素”之上。即可證明："float元素”的stack level級別較“block元素”高。因為如果同級,或者“block元素”的stack level高都應是“block元素”顯示在上。
根據以上，根據標准中的順序，把stack level高的元素代碼寫在前面，stack level低的代碼寫在後面，如果顯示結果是：代碼在前面的元素顯示在上方 ，即證明上面的stack level規則。
測試結果：
一些問題的解釋：
怿飛版主在《z-index在IE中的迷惑》一文中最後提到的問題：
運行代碼框
[Ctrl+A 全部選擇 提示：你可先修改部分代碼，再按運行]
演示地址：
http://rong179.blogbus.com/files/12163573190.Html
認為：
解惑：IE浏覽器似乎給body元素默認了一個相對定位屬性（position: relative）。
真是這樣嗎？
運行代碼框
[Ctrl+A 全部選擇 提示：你可先修改部分代碼，再按運行]
演示地址：
http://rong179.blogbus.com/files/12163572440.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的大小進一步決定顯示次序。
除此之外（也許設置其他屬性也會產生新的stacking context，但還不知道）只有定位元素設置了z-index(auto除外)才會產生新的stacking context，子元素將按照新的stacking context，定位。
在FF3.0中結果和標准順序一致。FF2.0中“z-index值為負值的定位元素”在父級stacking context的背景下面。（注意ff2.0的這個特殊性）
IE下測試
運行代碼框
[Ctrl+A 全部選擇 提示：你可先修改部分代碼，再按運行]
測試頁面：
http://rong179.blogbus.com/files/12163574751.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進一步決定顯示次序。