到新地方有些日子了，差不多适应了这边的工作节奏与流程。接到的第一个开发任务是几个比较简单的页面，需要做的工作就是先把设计图变成页面，然后使用PHP创建几个请求的接口传递数据，标准且简洁的web开发思路。可是真有些日子没有写DIV+CSS了，而且对IE6兼容性的坑碰到的还是不够多(以前做国外项目)，所以这次开发中不可避免的碰见了几个问题，尤其是在IE下的 z-index 问题很有意思，所以整理了一些资料和总结分享给大家...注：因为引入了jsfiddle，所以页面加载受影响会稍慢一些^_^
阅读目录：
- z-index属性
z-index规范参考
在IE下出现的问题
在IE6下z-index的问题
- >拼爹的时代
>万恶的float
- >用 iframe 包裹 select 元素
>以 Iframe 作为div的子元素，覆盖 select 元素
z-index属性
- z-index : auto | numberz-index 属性设置元素的堆叠顺序，如果为正数，则离用户更近，为负数则表示离用户更远；拥有更高堆叠顺序的元素总是会处于堆叠顺序较低的元素的前面；z-index 仅能在定位元素上奏效（position 属性值为 relative 或 absolute 或 fixed的对象）。
z-index规范参考
在IE下出现的问题
当定位元素的 'z-index' 未设置时（默认为 auto），在 IE6 IE7 IE8(Q) 下将会创建一个新的局部层叠上下文。而在其它浏览器下，则严格按照规范，不产生新的局部层叠上下文。
这个问题将导致定位元素的层叠关系在不同浏览器出现很大的区别，严重的可导致页面布局混乱、内容覆盖等。
受影响的浏览器有IE6 IE7 IE8(Quriks Mode)
直接从w3help复制了代码，分析以下代码：
注：Q代表Quriks Mode，即混杂模式。
根据 W3C CSS2.1 规范中的说明，定位元素【p1】和【p3】由于未设置 'z-index' 特性（使用默认值 auto），它们不会创建新的局部层叠上下文，而定位元素【p2】设置了 z-index:1 则会创建新的层叠上下文。
另，在同一根层叠上下文中，同为 z-index:auto 的定位元素【p1】和【p3】，它们的层叠级别相同，但【p3】在【p1】之后，所以在 Z 轴上【p3】比【p1】靠前显示，又，【p2】层叠上下文的层叠级别为正数，所以【p2】的层叠级别要比【p3】高。因此，它们在 Z 轴上的顺序为：（遵循 back-to-font）【p1】 -> 【p3】 -> 【p2】
以上为标准浏览器下的情况。
而在 IE6 IE7 E8(Q) 下，定位元素【p1】和【p3】都创建了新的局部层叠上下文，在同一根层叠上下文中，它们的层叠级别相同，但【p3】在【p1】之后，所以在 Z 轴上【p3】比【p1】靠前显示。此时，由于【p2】处于【p1】的层叠上下文中，所以【p2】在 Z 轴上要比【p3】靠后。
在来一个例子：
解决办法
理解层叠上下文、层叠级别与 'z-index' 之间的关系。在可能出现定位元素相互覆盖的情况时，明确指定定位元素的 'z-index' 特性，避免此问题的出现。
注：此段内容基本都是来自w3help。
在IE6下z-index的问题
我不是一个喜欢抱怨的人，so...有关抱怨IE6的话在此省略500字...
先上个图说说我在工作中实际遇到的问题：
图片的上半部分就是在非IE6下的交互，图片下半部分是在IE6下的显示效果，当打开虚拟机测试的时候我表示瞬间碉堡了，囧...在IE6下这个tips被盖住了，很明显这个不是我想要的效果，可是为什么会出现这个情况类？接着往下看。
分析此类问题的原因：
1.这是个拼爹的时代，在IE6下很好的体现了这点...囧
按照正常的思维，z-index层级越高，内容越应该在上面显示，在大部分的浏览器在大部分的情况下，确实如此，但是不绝对。尤其遇到IE6。
在IE6下的层级高低不仅要看本身，还要看自己的父元素是否给力：父元素的 position 属性为 relative或absolute 时，子元素的 absolute 属性是相对于父元素而言的。而在IE6下的层级的表现有时候不是看子元素的 z-index 多高，而要看它们的父元素的 z-index 谁高谁低。点击 Result 可以看到HTML对应的VIEW。
从