二更天为什么读:On having layout - 蓝色理想(4)

作者：old9　时间： 2006-06-30　文档类型：翻译　来自：web.Frontend

第 1 页 On having layout [1]
第 2 页 On having layout [2]
第 3 页 On having layout [3]
第 4 页 On having layout [4]
第 5 页 On having layout [5]

表格

table 总是有 layout 的，它总表现为一个已定义宽度的对象。在IE6中， 通常和一个宽度设为100%的表格相同，同时这也会带来很多问题(一些计算方面的错误)。另外在IE5.5和IE6的quirks模式下还有一些别的需要注意的情况。

相对定位元素(r.p.)

注意，由于 position: relative 并不触发 hasLayout，所以很多诸如内容消失或错位的渲染错误就会因此而起。这些现象可能会在刷新页面、调整窗口大小、滚动页面、选中内容等情况下出现。原因是 IE 在据这个属性对元素做偏移处理时，却似乎忘了发出信号让其 layout 孩子元素进行“重绘”(而如果是一个layout元素，那么在其重绘事件的信号链中，这个传给其孩子的信号是会正常发出的)。

·r.p. parent and disappearing floated child
·disappearing list-background bug

以上是一些相关问题的描述。作为经验之谈，相对定位一个元素时最好给予其 layout。再有，我们也需要检查拥有这种结构的父元素是否也需要 layout 或者position: relative亦或二者都需要，如果涉及到浮动元素这点就十分重要。

绝对定位元素(a.p.)：
包含区块，什么是包含区块？

理解 CSS 的包含区块概念很重要，它回答了绝对定位元素是相对哪里定位的问题：包含区块决定了偏移起点，包含区块定义了百分比长度的计算参考。

对于绝对定位元素，包含区块是由其最近的定位祖先决定的。如果其祖先都没有被定位，那么就使用初始包含区块 html。

通常情况下我们会用 position: relative 来设定任意包含区块。这就是说，我们可以让一个绝对定位元素所参考的原点和长度等不依赖于元素的排列顺序，这可以满足诸如“内容优先”这种可访问性概念的需要，也可以给复杂的浮动布局带来方便。

但是由于 layout 概念的存在，这种设计理念的效果在IE中就要打个问号了：因为在IE中绝对定位只有当其包含元素拥有 layout 时才会计算正确，而且绝对定位元素的百分比宽度参考也搞错了对象。这里 IE5 和 IE6 的行为不同但都有问题。IE7b2 的行为就要好很多，虽然有些小地方还是有错误。总之尽可能的让绝对元素的包含区块拥有 layout，而且尽量让其就是绝对定位元素的父级元素（也就是说这个包换元素和绝对定位元素之间没有绝对定位元素的别的祖先了）。

假设一个无 layout 的父元素被相对定位了——我们就得给它赋予 layout 才能使偏移量起作用：

·Absolutely Buggy II

假设一个未定位的父元素需要特定尺寸，而且页面设计是基于百分比宽度的——我们就可以放弃这个想法了，因为浏览器支持不佳：

·absolutely positioned element and percentage width

滤镜

MS专有的滤镜属性 filter　是只适用于 layout 元素的。有些滤镜扩展了对象的边界。它们会显示出自身特有的缺陷。

对已渲染元素的重排(re-flow)

当所有元素都已渲染完成时，如果有一个因鼠标经过而引起的变化产生(比如某个链接的 background 有变化)，IE会对其 layout 包含区块进行重排。有时一些元素就会因此被排到了新的位置，因为当这个鼠标经过发生时，IE已经知道了所有相关元素的宽度、偏移量等数据了。这在文档首次载入时则不会发生，那时由于自动扩张的特性，宽度还无法确定。这种情况会导致在鼠标经过时页面出现跳变。

·Jump on :hover
·quirky percentages: the reflow

这些和重排问题相关的 bug 会给百分比边距和补白使用较多的流动布局带来不少麻烦。

背景原点

MS专有的这个 hasLayout 还会影响背景的定位和扩展。比如，根据 CSS 规范，background-position: 0 0 应该指元素的“补白边缘(padding edge)”。而在 IE/Win 下，如果 hasLayout = false 则指的是“边框边缘(border edge)”，当 hasLayout=true 时指的才是补白边缘：

·Background, Border, hasLayout

边距重叠

hasLayout 会影响一个盒子和其子孙的边距重叠。根据规范，一个盒子如果没有上补白和上边框，那么它的上边距应该和其文档流中的第一个孩子元素的上边距重叠：

·Collapsing Margins
·Uncollapsing Margins

在 IE/Win 中如果这个盒子有 layout 那么这种现象就不会发生了：似乎拥有 layout 会阻止其孩子的边距伸出包含容器之外。此外当 hasLayout = true 时，不论包含容器还是孩子元素，都会有边距计算错误的问题出现。

·Margin collapsing and hasLayout

块级别的链接

hasLayout 会影响一个块级别链接的鼠标响应区域(可点击区域)。通常 hasLayout = false 时只有文字覆盖区域才能响应。而 hasLayout = true 则整个块状区域都可响应。添加了 onclick/onmouseover 等事件的任意块级元素也有同样的现象。

·Block anchors and hasLayout

在页面内使用键盘浏览：探索中
当使用 tab 在页面中浏览时，如果进入了一个页内链接(in-page link)，那么接下来再按的 tab 键就不会正常继续了：

·hasLayout Property Characterizes IE6 Bug
·Keyboard Navigation and Internet Explorer

tab 键会把用户带到(这通常是错误的)其最近的 layout 祖先中的第一个目标(如果这个祖先是由 table， div， span 或某些别的标签构成)。

收缩包围(shrink-wrapping)现象

给已经有 width: auto 的元素添加某些属性会导致它们在计算自身宽度时使用一种收缩包围的算法。比如这些属性 float: left|right, position: absolute|fixed, display: table|table-cell|inline-block|inline-table.

这些属性造成的现象在IE/Win中也存在，当然这是只对那些它支持的属性而言。但是当一个应该收缩包围的元素中包含一个拥有“layout”的块级元素时，在绝大多数情况下，这个孩子元素的宽度会尽可能地扩展而与其中包含的内容无关，同时也阻止了父元素的收缩包围现象。

例子：
一个浮动的纵向导航无序列表并没有收缩包围，因为其中的链接为了消除列表的多余空白bug并扩展可点击区域而拥有了 layout：a {display: block; zoom: 1;}。

这时收缩包围现象只有在以下情况仍然有效：拥有 layout 的孩子元素同时也被赋予了一个特定宽度，或者这个孩子元素本身也是一个具有收缩包围特性的元素，比如浮动元素。

边缘裁切

通常而言，当一个盒子包含了诸如伸出其边缘的内容这种更复杂的结构时，这个容器就经常需要“hasLayout”来避免一些渲染错误。但使用这种常用方法又会在边界处理时左右为难，因为一个获得“layout”的元素会变成某种自封闭的盒子。
内部的内容盒子会被裁切，比如使用负边距向外移动时。

·Clipping of negative margined blocks in a hasLayout container

被裁掉的部分当内容盒子触发了“layout”时可以再次出现，但在 IE6 中需要同时拥有 position: relative 才行。IE7 在这方面要略有改观，它不再需要额外的 position: relative 了。