On having layout
|
hasLayout 会影响一个块级别链接的鼠标响应区域(可点击区域)。通常 hasLayout = false 时只有文字覆盖区域才能响应。而 hasLayout = true 则整个块状区域都可响应。添加了 onclick/onmouseover 等事件的任意块级元素也有同样的现象。 Block anchors and hasLayout 在页面内使用键盘浏览：探索中当使用 tab 在页面中浏览时，如果进入了一个页内链接(in-page link)，那么接下来再按的 tab 键就不会正常继续了： Keyboard Navigation and Internet Explorertab 键会把用户带到(这通常是错误的)其最近的 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 了。 堆叠，分层和 layoutIE/Win 中似乎有两种分层和堆叠顺序： 一种是(伪)试图采用CSS的模式：Effect of z-index value to RP and AP blocks 还有一种是由“hasLayout”及其孪生兄弟“contenteditable”的行为产生的堆叠顺序。正如在上面相对定位的例子中展现的那样，在 layout 影响下的堆叠现象就好像 Harry Houdini (译者注：魔术师，以纸牌魔术成名)的拿手戏法儿一样。两种堆叠模式虽互不相容，但却共存于IE的渲染引擎中。经验之谈：调试的时候，两种情况都要考虑到。我们可能会有规律地在下拉菜单或者类似的复杂菜单中看到相关问题，因为它们往往牵涉到堆叠，定位和浮动等诸多令人头疼的问题。给那些 z-index 定位的元素 layout 是一种可能的修正方法，不过也不限于此，这里只是提醒一下。 混乱的 contenteditable如果给一个 HTML 标签设定 contenteditable=true 属性，比如<body contenteditable=true>，将会允许对该元素以及其 layout 子元素进行实时的编辑、拖动改变尺寸等操作。你可以把这属性用在浮动元素或者一个有序列表中的 layout 列表元素上看看效果。 为了对元素进行操作(编辑它们)，“contenteditable”和“hasLayout”为那些 hasLayout 返回 true 的元素引入了一套单独的堆叠顺序。 Editing Platform 继承了 layout 概念，对 layout 的误解多是因 contenteditable 而起即可作为证明(那些某种程度上集成了IE编辑引擎的应用软件多暗含着对layout概念的某种强制向后兼容性)。 More on contenteditable 和 CSS 规范类似的地方你的 MSIE 页面在别的浏览器中一团糟？我们可没必要让这种事情发生。如果使用恰当，任何好的浏览器都能摆平 MSIE 的页面——只要你使用一些正确的 CSS。 利用 hasLayout 和“”之间的细微相似之处，我们可以有几种方法在标准兼容浏览器中重新实现 hasLayout 的“”效果，和一些“”所特有的效果。 Reverse engineering series Simulations Quirks 模式关于这种渲染模式的的信息，请参考我们的 quirks 模式章节。 Layout ——结论整个 layout 概念和一些基本 CSS 概念是不兼容的，即包含，排列，浮动，定位和层叠等。 由于页面中元素或有或没有 layout，会导致 IE/Win 的行为和 CSS 规范相违背。 拥有 layout ——另外一个引擎？
IE 的对象模型看起来是文档模型和他们传统的应用程序模型的糅合。我之所以提到这点是因为它对于理解IE如何渲染页面很重要。而从文档模型切换到应用程序模型的开关就是给一个元素“layout”。 () 有时候要解释清楚某种行为是不可能的：就比如 hasLayout，会根据它的状态选择两种不同渲染引擎的一种使用，而且每一种都有其自己的 bug 和怪异之处。 不可消除的 bug
软件 bug 是由于在制作过程中对完整性和逻辑问题考虑不周等人为错误而导致的。这是人类的固有缺陷，目前还没有什么好的解决方法。 同样由于这种缺陷，任何试图不重写软件而修复 bug 的做法，都将会不可避免的导致软件中出现更复杂的bug。 所有依赖别的软件的软件——当然包括依赖操作系统，也会同样依赖他们的 bug。于是我们会从所有关联的软件中得到一连串的 bug，这也更说明找到一个无 bug 软件是几乎不可能的。 (Molly, the cat‛) 本文创建于2005年6月30日，最后一次修改于2006年4月2日。 编者： Holly Bergevin Ingo Chao Bruno Fassino John Gallant Georg Sørtun Philippe Wittenbergh特别致谢给予此项目支持的： Dean Edwards, and Molly ‚the cat‛ 各种语言版本： Original(English) Brazilian Portuguese by Mauricio Samy Silva 中文版本 by old9 Italian by Gabriele Romanato 相关讨论： dean.edwards.name/weblog/ 联系作者： spam.layout@satzansatz.de 版权说明： 本文基于创作共用协议发布。 （编辑：焦作站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
