当使用 tab 在页面中浏览时，如果进入了一个页内链接(in-page link)，那么接下来再按的 tab 键就不会正常继续了：
Keyboard Navigation and Internet Explorertab 键会把用户带到(这通常是错误的)其最近的 layout 祖先中的第一个目标(如果这个祖先是由 table， div， span 或某些别的标签构成)。
堆叠，分层和 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 模式某些 doctype，或者 <xml> 声明，在 IE6 中会触发“quirks模式”或曰向后兼容模式。在这种模式下，IE6 就像 IE5.5，并且和它老弟拥有一样的bug，一样的问题和一样的行为。
而对于IE7，<xml> 声明不会再改变渲染模式了；要触发 quirks 模式，我们不得不插入一个注释才行。(IE7 的 quirks 模式和 IE6 的 quirks 模式是否一样还有待验证)
<?xml version="1.0" encoding="utf-8"?> <!-- ... 让 IE7 运行在 quirks 模式 --> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> Layout — 结论整个 layout 概念和一些基本 CSS 概念是不兼容的，即包含，排列，浮动，定位和层叠等。
由于页面中元素或有或没有 layout，会导致 IE/Win 的行为和 CSS 规范相违背。
拥有 layout — 另外一个引擎？
IE 的对象模型看起来是文档模型和他们传统的应用程序模型的糅合。我之所以提到这点是因为它对于理解IE如何渲染页面很重要。而从文档模型切换到应用程序模型的开关就是给一个元素“layout”。
()
有时候要解释清楚某种行为是不可能的：就比如 hasLayout，会根据它的状态选择两种不同渲染引擎的一种使用，而且每一种都有其自己的 bug 和怪异之处。
不可消除的 bug
软件 bug 是由于在制作过程中对完整性和逻辑问题考虑不周等人为错误而导致的。这是人类的固有缺陷，目前还没有什么好的解决方法。
同样由于这种缺陷，任何试图不重写软件而修复 bug 的做法，都将会不可避免的导致软件中出现更复杂的bug。