在斯芬克斯——ie私有属性haslayout这篇文章中，我们提到的第一个斯芬克斯之迷，其实就是一个margin叠加问题。
关于margin collapsing，在W3C中是有明文规范的，符合其规则的都将产生margin collapsing。W3C认为margin叠加后的布局界面更良好。
margin叠加现象（父子级别）：
可以看出wrap未被子层的margin所撑开。
但是，这种margin叠加往往不是我们所想要的效果（一些人甚至将此称为一个bug：margin叠加bug，也有称高度不适应bug的）——平心而论，我们努力的要避开margin collapsing多少也有些违背了W3C的初衷。不过，由于ie下经常有意无意的会触发haslayout，从而会避开margin叠加，这使得浏览器间显示不一。因此，我们还是有理由在适当时候彻底避开margin叠加的。
那么，如何避免这种margin叠加现象呢？
(全文…)
就象神话中的斯芬克斯一样，ie的私有属性haslayout是个神秘且让人困惑的难缠东西，她只游荡于ie（这片沙漠）之下。
她无法使用css声明直接创建。即便是对于ie，她也不能说是一个实实在在存在的属性。
ie下的元素有些本身拥有haslayout（基本上是一些拥有内在尺寸的可置换元素）,有些可以通过一些css属性可以触发产生。
我们可以在ie developer toolbar上查看到到haslayout这个属性项，他的值是-1。这说明这个元素触发了layout。
详细haslayout资料：On having layout抄录
更详细资料：译文On having layout这篇文章本人还没怎么看，相信很多问题在这里都有解释
遇到斯芬克斯是件很麻烦的事情，她会给你提出很多怪怪的让人困惑的问题，更何况只要我们在ie沙漠中游荡的话，遇到的概率是非常高的。
遇到她，我们会有三种结果：
猜不出迷题的答案——我们会在迷失在困惑中；
猜错了迷题的答案——我们会误会很多东西；
猜对了迷题的答案——恭喜你，你就不用怕斯芬克斯这个丑婆娘了。
那让我们来猜一下她的几个比较困惑的问题吧。
(全文…)
上次我将遇到的ie bug发到blueidea上后。有人说是由于ul没触发layout产生的问题。虽然之前经常听到haslayout这个词，但一直没有看过。
网上找了一篇资料阅读了一下。果然明朗多了。
文章地址：http://bbs.blueidea.com/thread-2636904-1-1.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 以及预先测试得出。
前些天，工作时候碰到的一个ie bug。虽费了些功夫解决掉了，但始终搞不明白这个bug(当然bug都是很难捉摸的)。
现在还原这个bug,记录于此，也不知道以后还会不会碰上这个bug了。我想是比较难遇的，因为，产生这个bug的必要因素很多，少了任何一个，这个bug就生不出来了。
看代码：(注释部分是解决方法，任一一种就能解决)