IT技术博客大学习 共学习 共进步
全部 移动开发 后端 数据库 AI 算法 安全 DevOps 前端 设计 开发者

定位元素间的Z值比较及z-index在不同浏览器下默认值的影响

Codyy技术团队 2009-10-14 13:36:27 累计浏览 3,745 次
本机暂存

     z-index在ie下缺省为:z-index:0; 而FF下则缺省为:z-index:auto;

    (这个结论已然在蓝色的《补遗 》这个帖子中得出。而本文的讨论也是对《补遗》的总结及延伸。 )

    你可以借助ie developer tool和firebug等工具进行测试查看z-index值。需要注意的是:z-index值须在设置position:relative/absolute/fixed之后方才生效。

    正是IE/FF下这一点区别导致ie,ff下z值的不同表现。

    注意:此处所说的z值区别于z-index,它指的是z轴层叠等级(stack level),表示垂直于显示屏方向上的各层的层叠顺序。不止z-index一个属性会影响到z轴层叠等级的大小(本文对其他属性的影响暂不做讨论,但本文的研究已排除其他属性的影响,其他属性不会影响本文的研究)。

    正常情况下:兄弟(同级)元素后者居上,父子之间子高于父。

    这一点必须明确,相信也没什么异见。

    可以看下面这个demo:

    

父级1
子级1
父级2
子级2

     提示:您可以先修改部分代码再运行

    可以看出z的等级:子级2(“堂弟”)>父级2(“叔叔”)>子级1(“子”)>父级1(“父”)。

    如果我们想要父盖过子,兄罩着弟只需设置其z-index便可。z-index值越大,给予的z值就越大。

    那么这个设置能否改变叔侄之间,堂兄弟之间的Z呢?

    先试试看:

    

父级1
子级1
父级2
子级2

     提示:您可以先修改部分代码再运行

    看上去一样有效,是吧?子级1盖过了父级2和子级2。

    但是,再看看下面这个例子,假如各级元素都是定位元素(设置了position),情况就有些不同了(之后的讨论,都是基于这个条件之下的。我觉得position定位的应用非常广泛,基于此的研究也非常有必要)。

    

父级1
子级1
父级2
子级2

     提示:您可以先修改部分代码再运行

    son1设置z-index:1000后,在FF下的z值级别就高于其叔与其堂弟father2,son2。但是在ie下这个设置却还是不行。

    这时候,我们回过头看最前面的结论:z-index在ie下缺省为:z-index:0; 而FF下则缺省为:z-index:auto;

    那么再写一个Test,将父级的z-index固定为0:

    

父级1
子级1
父级2
子级2

     提示:您可以先修改部分代码再运行

    可以看出,一旦父级元素设置了相同的z-index,ff下“侄”元素一样无法超过“叔”元素和“堂弟”元素。

    我们可以试着得出这么一个结论:

    对于定位元素,(不论IE还是FF)非同级关系和非父子关系元素之间的Z值大小比较,须要回溯至其为兄弟关系的两个祖先元素上,先比较这两个元素的z-index值,只有当“兄”的z-index大于“弟”的z-index值,“兄”的各个后代元素,才能超过“弟元素”及其子孙元素。

    我们用一个三级关系来验证一下。

    

祖父级
父级
子级
祖父级
父级
子级

     提示:您可以先修改部分代码再运行

    不论#first .father和#first .son如何设置,只有#first的z-index值大于0(second的z-index值为0)时,才能盖住#second。

    对于IE,元素的z-index缺省值是0,如果不另外设置“兄”,“弟”元素的z-index值,那么”兄”的z-index就无法大于“弟”的z-index。那么”兄”元素及其子孙就无法盖过”弟”元素及其子孙。而一旦“兄”的z-index大过了”弟”元素的z-index,那么情况就翻转了,“弟”元素及其子孙将无法盖过“兄”元素及其子孙。

    而对FF,元素的z-index缺省值是auto,auto的意思是什么,就是说“随便,不关我事”,那么子孙们的z值等级就只跟他们自己本身的z-index有关了。

    那么,IE上能否设置z-index:auto;呢?

    测试:

    

祖父级
父级
子级
祖父级
父级
子级

     提示:您可以先修改部分代码再运行

    可以看出,在IE下,去除#first{z-index:1}后,#first及其子孙无法盖住#second。

    而FF下,#first .father,#first .son却盖住了整个#second。

    推论:

    z-index:auto在ie下无效。

    那么在IE下,对于由定位元素构成的两个并列的嵌套结构块间的Z值大小,只存在两种情况:要么这个结构块里的所有层元素都在另一个结构块之上,要么就是那个结构块所有元素在其之上。没有可能一个元素能插在另一个结构块的父与子之间,这种情况在FF下是存在的(当然,还有其他浏览器),在FF下,父级是z-index:auto的元素,他们都是自由的,依据自己的z-index决定Z值。FF下甚至可以形成:

    ――――-

    ~~~~~~~~

    ――――-

    ~~~~~~~~

    这么一个四层交错,但要超过四层,就无能为力了。

    

祖父级
父级
子级
祖父级
父级
子级

     提示:您可以先修改部分代码再运行

    最后,还是要提醒一下,这里的讨论限于定位元素间。

    ―――补充――――-

    z-index:auto在ie中无效?

    关于z-index:auto的解释,在W3C的CSS说明文档中的解释是:

    The stack level of the generated box in the current stacking context is the same as its parent’s box. The box does not establish a new local stacking context.

    即Z的层叠等级将继承父级,不创建新的层叠内容。

    这段说明在CSS2和CSS2.1中是完全一致的,那为什么ie”不支持” z-index:auto呢?

    在css2中有一段css2.1中所没有的解释:

    An element that establishes a local stacking context generates a box that has two stack levels: one for the stacking context it creates (always ‘0′) and one for the stacking context to which it belongs (given by the ‘z-index’ property).

    一个元素创建的层叠内容框包含两个层叠等级,一个是就是创建的层叠内容(总是“0”),另一个就是这个层叠内容包含的子层叠内容(由“z-index”属性决定)。

    所以在ie当中,即便某元素设置z-index:auto,它所继承的z也是0。

    这貌似同我们文章中第一段结论一致。也勉强解释了为什么z-index:auto在IE中无效。

同分类推荐文章

  1. 新特性速递:focus()行为新增focusVisible控制 (2026-05-29 16:23:06)
  2. Algorithmic Theming Engines: Building Self-Correcting Color Systems With `contrast-color()` (2026-05-28 21:00:00)
  3. Revealing Text With CSS letter-spacing (2026-05-27 20:37:33)

查看更多 前端 文章 →

建议继续学习

  1. 50个活力和动感的网页设计-颜色的灵感 (累计阅读 34,363)
  2. 视觉设计前瞻实用性研究(PNVD) 第二期 (累计阅读 12,905)
  3. 各公司对前端开发的职位描述 (累计阅读 10,345)
  4. iframe大小自适应 (累计阅读 9,985)
  5. 浏览器的渲染原理简介 (累计阅读 8,282)
  6. 解决IE6从Nginx服务器下载图片不Cache的Bug (累计阅读 8,284)
  7. iframe里src="about:blank"的问题。 (累计阅读 7,983)
  8. 程序员眼里IE浏览器是什么样的 (累计阅读 7,942)
  9. 2010网页设计趋势 (累计阅读 7,741)
  10. Web前端工程师编程能力飞升之路 (累计阅读 7,613)