margin collapsing（css2.1规范）
margin collapsing（css2规范）

margin叠加现象（父子级别）：

可以看出wrap未被子层的margin所撑开。

但是，这种margin叠加往往不是我们所想要的效果（一些人甚至将此称为一个bug：margin叠加bug，也有称高度不适应bug的）——平心而论，我们努力的要避开margin collapsing多少也有些违背了W3C的初衷。不过，由于ie下经常有意无意的会触发haslayout，从而会避开margin叠加，这使得浏览器间显示不一。因此，我们还是有理由在适当时候彻底避开margin叠加的。

那么，如何避免这种margin叠加现象呢？

从《斯芬克斯——ie私有属性haslayout》那篇文章中，我们知道，ie下触发haslayout可以避开margin叠加。那么其他浏览器呢？

我们先看一下另两种解决方法。
方法一：在父级内部的添加上、下两个空元素。
有些教科书上将这种方法称为完美的解决方法。但实际当中我们一般不会使用，因为这种方法不仅要多加两个无意义元素标签，对这两个元素还要特别设置CSS使其高度为0。）:

第二种，在父级上使用border属性（属性值0和none除外）。
这个方法也不大经常使用，因为在wrap上至少要设置一个1px的多余边框（上下两个就是2px）,而且这条边线的颜色的颜色设置也是个问题，因为可能在wrap内部会使用背景图片(background-image),那么这条边线就无法伪装隐藏了。

最后一个方法，就利用到了ie的haslayout原理了（清除浮动也用到了这种方法）。对于ff下，在父级（wrap）上使用overflow:hidden；对于ie则触发其layout——如何触发，可以看这篇文章：on having layout。

（overflow：hidden也会触发ie7中的layout。但是对之前的ie版本无效，否则倒是可以一个属性搞定）。

Related posts:

1. 斯芬克斯之迷——ie私有属性haslayout的困扰 就象神话中的斯芬克斯一样，ie的私有属性haslayout是个神秘且让人困惑的难缠东西，她只游荡于ie（这片沙漠）之下。 她无法使用css声明直接创建。即便是对于ie，她也不能说是一个实实在在存在的属性。 ie下的元素有些本身拥有haslayout（基本上是一些拥有内在尺寸的可置换元素）,有些可以通过一些css属性可以触发产生。 我们可以在ie developer toolbar上查看到到haslayout这个属性项，他的值是-1。这说明这个元素触发了layout。 详细haslayout资料：On having layout抄录 更详细资料：译文On...
2. 一种不常用的布局——中间列宽度固定，左右列自适应宽 三列布局，中间列宽度固定，左右列自适应宽。 在蓝色理想上的一个提问。 这种布局一般来说不大会用上。 （而相对比较常见的是这种布局：左右列固定高度，中间列自适应宽度。 之前写过一种此结构的扩展结构：三列自适应等高且中列宽度自适应布局） 用css来实现这种不常见的结构着实也不太容易（或许也是这种结构不流行的一个原因吧）。 实现主要难点在于左右列的宽度计算，假设中间列的宽度为Y,那么左右列的宽度就应该是(100%-Y)/2(左右列等宽情况下)。但是CSS又不支持这种算式计算（当然，ie下有expression，但是这种不标准的东西我们一向是不屑的）。 历数css中，唯一有减法效果的也就margin边距这么一种属性。 所以，我们找到了我们的独木桥——margin。 上下级包含的结构中，如果上级元素（block类型）固定宽度为X，下级元素不定宽，而设置属性margin:50px;那么下级元素的宽度就等于X-2×50px。...
3. 不同编码、浏览器下的尺寸（dimension） 首先，说明下，第一次测试忽视了一个属性在不同编码，浏览器下的不同解释造成的尺寸不同，即line-height属性。 可以看出： 1，gb2312编码下： 未定高度,由文字填充的block元素在ff和ie下高度一致， 只是inline元素在ie7中要比在ff中较高。 2，utf-8编码下： inline,block(未定宽高)元素ie和ff的差别就大了。(ff中的inline,block元素都要比ie7中较高) 3.不论在gb2312或utf-8编码下，ff3的显示都是一致的（对照第一幅的左半边和第二幅的左半边）。 而ie7中相差就比较大了（gb2312编码下的inline,block元素都要比utf-8的高）。 4.ff下的bloak元素边框与文字间，上下有一定的间隙（类似padding，但无法去除）。...

我们可以在ie developer toolbar上查看到到haslayout这个属性项，他的值是-1。这说明这个元素触发了layout。
详细haslayout资料：On having layout抄录
更详细资料：译文On having layout这篇文章本人还没怎么看，相信很多问题在这里都有解释

遇到斯芬克斯是件很麻烦的事情，她会给你提出很多怪怪的让人困惑的问题，更何况只要我们在ie沙漠中游荡的话，遇到的概率是非常高的。
遇到她，我们会有三种结果：
猜不出迷题的答案——我们会在迷失在困惑中；
猜错了迷题的答案——我们会误会很多东西；
猜对了迷题的答案——恭喜你，你就不用怕斯芬克斯这个丑婆娘了。

那让我们来猜一下她的几个比较困惑的问题吧。

斯芬克斯之迷1：是firefox错了？

left是浮动元素，她脱离了文档流（注意，这是下一个斯芬克斯之迷），所以right的margin-top相对的是其上级wrap作用的。但我们只是对right设置margin-top。结果在FF下，怎么连left也“产生了margin-top”呢。对比ie和FF下的效果，是不是觉得IE下的解析会比较合理呢？
但是
别忘了影响margin-top/bottom的一个重要规则——margin塌陷（margin collapsing）。

margin collapsing（css2.1规范）
margin collapsing（css2规范）

在ff下就是产生了这么一个margin塌陷。导致wrap的”剥夺”了本属于子元素#right的margin-top值。
为了更加直观看出是否塌陷，可以給wrap添加一个背景：background:#000；

在ff下wrap块的高度并没有被子元素right的margin-top撑开。反而自身拥有了50px的margin-top。
而浮动的left尽管脱离了文档流，但还是受其父级限制的（这跟absolute定位的元素层受限于其定义为relative的父级一样）。所以left还是包含在wrap之中，这样在ff下看起来left也拥有margin-top，而事实上是因为wrap高度不撑开的结果。

这么说,FF并没有错咯,那么IE下又是怎么避开margin塌陷的呢？
问题就出在浮动上面，在ie下，元素浮动将触发其haslayout。就是这个原因，使得在ie下意外（意外？）的就避开了margin塌陷。
haslayout差点让我们怀疑了我们的亲密伙伴firefox。

———-谜题之外———–
但是，margin塌陷往往不是我们想要的效果。那么我们需要怎么避开他呢？
可以看下这篇独立文章：如何解决麻烦的margin塌陷(margin collapsing)

斯芬克斯之迷2：在ie下，float元素不脱离文档流？

在前面的问题里，我们提到浮动元素时一直认为浮动元素脱离文档流。但是看一下下面这个现象：

很多人都一直怀疑浮动元素脱离文档流的这种说法，就是因为ie下haslayout的经常出现。ie下，浮动的元素（left）牢牢的占着自己的位置。后面的block元素（right），只能跟随其后（请对比FF下的效果）。
没错，这又是haslayout在迷惑我们，这回除了left因为浮动触发了haslayout外，right也由于使用了width:500px也触发了haslayout，使得他考虑到了前面浮动的left元素。
如果把right的宽度去掉，或则把值改成auto。就能使ie下达到ff下一样的效果：后面的block元素会忽略前面浮动元素的存在，直接跑到浮动元素的z轴方向的下面（为什么是下面？因为浮动元素的Z值较正常的要高），而inline元素则环绕此浮动元素。
我们再看一个更加明了的demo:

由于父级使用width:100%.触发了haslayout。使得原本脱离文档流的浮动元素，又在其父级之内拥有了一席之地。

——-谜题之外——–
浮动有三个作用效果：
一是使得自身脱离文档流，使得父层不适应其高度,而后面的block元素也将忽略其“存在”，跑到浮动元素之下（可在block元素上加背景色查看）；
二是使得后面的inline元素“顺流环绕”浮动元素。
三是浮动元素的尺寸，如果未定义的话，将按内部元素的尺寸来决定（而不是block元素默认的充满整行）。而且即便浮动元素本身是非可置换inline元素，她都可以定义width/height(还有margin也将算入尺寸计算)。
其实第一个效果往往不是我们所想要的。所以ie下的haslayout可以说正中我们下怀。那么FF下怎么让left元素不脱离文档流（看起来没有脱离）呢？
在上面的例子中，我们可以对right也使用浮动，或则在right加上overflow:hidden。
知道了这个原理，我们对于这个【右列宽度自适应】的布局（其实这是个左右布局均自适应的布局。一般来说我们会固定左列的宽度）就能很好理解了：
zoom:1针对IE系列触发haslayout.overflow:hidden针对FF。使得right不会忽视已经脱离文档流的浮动元素left。

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /> <title>二列，右列自适应宽度布局</title> <style type="text/css"> *{padding:0;margin:0;} .wrap{overflow:hidden;} #left{float:left;color:red;} #right{background:#ccc;zoom:1;overflow:hidden;} </style> </head> <body> <div class="wrap"> <div id="left"> left </div> <div id="right"> 更多右列宽度自适应布局的方法：<a href="http://www.cssass.com/blog/index.php/2008/31.html">http://www.cssass.com/blog/index.php/2008/31.html</a></div> </div> </body> </html>

IE下的haslayout会引发很多问题：

IE 很多常见的浮动 bug 。
元素本身对一些基本属性的异常处理问题。
容器和其子孙之间的边距重叠(margin collapsing)问题。
使用列表时遇到的诸多问题。
背景图像的定位偏差问题。
使用脚本时遇到的浏览器之间处理不一致的问题。

她经常让我们困惑不堪。
但是只要逐步认识她，重视她。经常怀疑，怀疑自己的怀疑。我们就能慢慢摸清她的谜题，了解问题的本质。

Related posts:

1. 如何避开麻烦的margin叠加(margin collapsing) 在斯芬克斯——ie私有属性haslayout这篇文章中，我们提到的第一个斯芬克斯之迷，其实就是一个margin叠加问题。 关于margin collapsing，在W3C中是有明文规范的，符合其规则的都将产生margin collapsing。W3C认为margin叠加后的布局界面更良好。 margin collapsing（css2.1规范） margin collapsing（css2规范） margin叠加现象（父子级别）： <!DOCTYPE...
2. 一种不常用的布局——中间列宽度固定，左右列自适应宽 三列布局，中间列宽度固定，左右列自适应宽。 在蓝色理想上的一个提问。 这种布局一般来说不大会用上。 （而相对比较常见的是这种布局：左右列固定高度，中间列自适应宽度。 之前写过一种此结构的扩展结构：三列自适应等高且中列宽度自适应布局） 用css来实现这种不常见的结构着实也不太容易（或许也是这种结构不流行的一个原因吧）。 实现主要难点在于左右列的宽度计算，假设中间列的宽度为Y,那么左右列的宽度就应该是(100%-Y)/2(左右列等宽情况下)。但是CSS又不支持这种算式计算（当然，ie下有expression，但是这种不标准的东西我们一向是不屑的）。 历数css中，唯一有减法效果的也就margin边距这么一种属性。 所以，我们找到了我们的独木桥——margin。 上下级包含的结构中，如果上级元素（block类型）固定宽度为X，下级元素不定宽，而设置属性margin:50px;那么下级元素的宽度就等于X-2×50px。...
3. CSS多类选择符测试 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html...

抄录一些：

Internet Explorer 中有很多奇怪的渲染问题可以通过赋予其“layout”得到解决。John Gallant 和 Holly Bergevin 把这些问题归类为“尺寸bug(dimensional bugs)”，意思是这些 bug 可以通过赋予相应元素某个宽度或高度解决。

“Layout”是一个 IE/Win 的私有概念，它决定了一个元素如何显示以及约束其包含的内容、如何与其他元素交互和建立联系、如何响应和传递应用程序事件/用户事件等。
这种渲染特性可以通过某些 CSS 属性被不可逆转地触发。而有些 HTML 元素则默认就具有“layout”。

Layout 在显示盒子时有着不同寻常而且难以预料的效果，而且有时甚至会牵连到他们的孩子元素。
一个元素是否具有“layout”可能会引发如下的一些问题：
  IE 很多常见的浮动 bug 。
  元素本身对一些基本属性的异常处理问题。
  容器和其子孙之间的边距重叠(margin collapsing)问题。
  使用列表时遇到的诸多问题。
  背景图像的定位偏差问题。
  使用脚本时遇到的浏览器之间处理不一致的问题。

不同于标准属性，也不像某些浏览器的私有 CSS 属性，layout 无法通过某一个 CSS 声明直接设定 。也就是说没有“layout属性”这么一个东西，元素要么本身自动拥有 layout，要么借助一些 CSS 声明悄悄地获得 layout。
默认layout元素
下列元素应该是默认具有 layout 的：
<html>, <body> <table>, <tr>, <th>, <td> <img> <hr> <input>, <select>, <textarea>, <button> <iframe>, <embed>, <object>, <applet> <marquee>

下列 CSS 属性和取值将会让一个元素获得 layout：
position: absolute
绝对定位元素的包含区块(containing block)就会经常在这一方面出问题。
float: left|right
由于 layout 元素的特性，浮动模型会有很多怪异的表现。
display: inline-block
当一个内联级别的元素需要 layout 的时候往往就要用到它，这也可能也是这个 CSS 属性的唯一效果——让某个元素拥有 layout。“inline-block行为”在IE中是可以实现的，但是非常与众不同： IE/Win: inline-block and hasLayout 。
width: 除 “auto” 外的任意值
很多人遇到 layout 相关问题发生时，一般都会先尝试用这个来修复。
height: 除 “auto” 外的任意值
height: 1% 就在 Holly Hack 中用到。
zoom: 除 “normal” 外的任意值 (MSDN)
MS专有属性，无法通过校验。 不过 zoom: 1 可以临时用做调试。
writing-mode: tb-rl (MSDN)
MS专有属性，无法通过校验。

·在 IE7 中，overflow 也变成了一个 layout 触发器：

overflow: hidden|scroll|auto
这个属性在之前版本 IE 中没有触发 layout 的功能。
overflow-x|-y: hidden|scroll|auto
overflow-x 和 overflow-y 是 CSS3 盒模型中的属性，尚未得到浏览器的广泛支持。他们在之前版本IE中没有触发 layout 的功能。

·另外 IE7 的荧幕上又新添了几个 haslayout 的演员，如果只从 hasLayout 这个方面考虑，min/max 和 width/height 的表现类似，position 的 fixed 和 absolute 也是一模一样。

position: fixed
./.
min-width: 任意值
就算设为0也可以让该元素获得 layout。
max-width: 除 “none” 之外的任意值
./.
min-height: 任意值
即使设为0也可以让该元素的 haslayout=true
max-height: 除 “none” 之外的任意值
./.

以上结论借助 IE Developer Toobar 以及预先测试得出。

Related posts:

1. 关于浮动与浮动清理 浮动不清理会导致很多问题。(当然，有时候，这种问题就是我们要的效果。) 容器不扩展问题，这是浮动导致的众多问题中的一个哈。 这个问题相对于其他常规的由浮动引起的文档流的改变还是有区别的。 我一向不大同意float元素“脱离文档流”的之说，而比较认可“改变文档流”的说法。脱离文档流（如position:absolute）会导致外容器不扩展这 其实很正常。但改变文档流会引起外容器不扩展这个问题，我就会当成bug来看待了。 清除浮动，不仅能恢复被改变的文档流，也能修复这个bug。不多提了。 关于清除浮动，我一向用教材里学的clear方法。有些人，分不清什么时候clear:left;什么时候用clear:right;而一mein地在空标签中使用clear:both.  其实，前面有float:left;要清的话，就用clear:left;有right就对应用right。 最近老是接触到overflow:hidde;这种清除浮动的方法。但由于不明白原理，一直是束之高阁。今天初探一番： 要说overflow:hidden;能请浮动的话，overflow:auto;也未尝不可啊。ie7,ff下试了一番，全部都通过。...
2. 改变元素display属性的垂直居中方法。 之前也有搜集过纯CSS的几种方法。 但觉得没有下面的好。 <!DOCTYPE HTML> <html> <head> <meta charset="utf-8" /> <style...
3. footer始终固定于窗口底部(支持ie6的fixed效果) <!DOCTYPE html> <html> <head> <style type="text/css"> *{padding:0;margin:0;} html,body{ _height:100%;...

Related posts:

1. 如何避开麻烦的margin叠加(margin collapsing) 在斯芬克斯——ie私有属性haslayout这篇文章中，我们提到的第一个斯芬克斯之迷，其实就是一个margin叠加问题。 关于margin collapsing，在W3C中是有明文规范的，符合其规则的都将产生margin collapsing。W3C认为margin叠加后的布局界面更良好。 margin collapsing（css2.1规范） margin collapsing（css2规范） margin叠加现象（父子级别）： <!DOCTYPE...
2. 斯芬克斯之迷——ie私有属性haslayout的困扰 就象神话中的斯芬克斯一样，ie的私有属性haslayout是个神秘且让人困惑的难缠东西，她只游荡于ie（这片沙漠）之下。 她无法使用css声明直接创建。即便是对于ie，她也不能说是一个实实在在存在的属性。 ie下的元素有些本身拥有haslayout（基本上是一些拥有内在尺寸的可置换元素）,有些可以通过一些css属性可以触发产生。 我们可以在ie developer toolbar上查看到到haslayout这个属性项，他的值是-1。这说明这个元素触发了layout。 详细haslayout资料：On having layout抄录 更详细资料：译文On...
3. 一种不常用的布局——中间列宽度固定，左右列自适应宽 三列布局，中间列宽度固定，左右列自适应宽。 在蓝色理想上的一个提问。 这种布局一般来说不大会用上。 （而相对比较常见的是这种布局：左右列固定高度，中间列自适应宽度。 之前写过一种此结构的扩展结构：三列自适应等高且中列宽度自适应布局） 用css来实现这种不常见的结构着实也不太容易（或许也是这种结构不流行的一个原因吧）。 实现主要难点在于左右列的宽度计算，假设中间列的宽度为Y,那么左右列的宽度就应该是(100%-Y)/2(左右列等宽情况下)。但是CSS又不支持这种算式计算（当然，ie下有expression，但是这种不标准的东西我们一向是不屑的）。 历数css中，唯一有减法效果的也就margin边距这么一种属性。 所以，我们找到了我们的独木桥——margin。 上下级包含的结构中，如果上级元素（block类型）固定宽度为X，下级元素不定宽，而设置属性margin:50px;那么下级元素的宽度就等于X-2×50px。...