We all know that browsers can be buggy, and IE on Windows seems buggier than most. One of the reasons IE/Win behaves differently from other browsers is because the rendering engine uses an internal concept called “layout.” Because layout is a concept particular to the internal working of the rendering engine, it is not something you would normally need to know about. However, layout problems are the root of many IE/Win rendering bugs, so it is useful to understand the concept and how it affects your CSS.

What is “layout”?

Internet Explorer on Windows uses the layout concept to control the size and positioning of elements. Elements that are said to “have layout” are responsible for sizing and positioning themselves and their children. If an element does not “have layout,” its size and position are controlled by the nearest ancestor with layout. The layout concept is a hack used by IE’s rendering engine to reduce its processing overhead. Ideally all elements would be in control of their own size and positioning. However, this causes huge performance problems in IE. As such, the IE/Win development team decided that by applying layout only to those elements that actually needed it, they could reduce the performance overhead substantially.

Elements that have layout by default include

• body
• html in standards mode
• table
• tr, td
• img
• hr
• input, select, textarea, button
• iframe, embed, object, applet
• marquee

The concept of layout is specific to IE on Windows, and is not a CSS property. Layout cannot be explicitly set in the CSS, although setting certain CSS properties will give an element layout. It is possible to see if an element has layout by using the JavaScript function, hasLayout. This will return true if the element has layout and false if it doesn’t. hasLayout is a read-only property and so cannot be set using JavaScript.

Setting the following CSS properties will automatically give that element layout:

• position: absolute
• float: left or right
• display: inline-block
• width: any value
• height: any value
• zoom: any value (Microsoft property—doesn’t validate)
• writing-mode: tb-rl (Microsoft property—doesn’t validate)

What effect does layout have?

Layout is the cause of many IE/Win rendering bugs. For instance, if you have a paragraph of text next to a floated element, the text is supposed to flow around the element. However, in IE 6 and below on Windows, if the paragraph has layout—by setting the height, for example—it is constrained to a rectangular shape, stopping the text from flowing around the float (see Figure below).

Figure Above: Text is supposed to flow around adjacent floated elements. However, on IE/Win, if the text element has layout, this doesn’t happen.

Another problem revolves around how elements with layout size themselves. If the content of an element becomes larger than the element itself, the content is supposed to flow out of the element. However, in IE 6 and below on Windows, elements with layout incorrectly grow to fit the size of their contents (see Figure below).

Figure Above: Elements with layout incorrectly grow to fit their contents.

This means that width in IE/Win actually acts more like a min-width. This behavior is also the cause of many broken floated layouts in IE/Win. When the content of a floated box incorrectly forces the width of the box to grow, the box becomes too big for the available space and drops below the other floated elements.

Other problems include

• Elements with layout not shrinking to fit
• Floats being auto-cleared by layout elements
• Relatively positioned elements not gaining layout
• Margins not collapsing between elements with layout
• The hit area of block-level links without layout only covering the text

In the next section, we are going to cover some of the most common browser bugs, and you will notice that many of the fixes for IE on Windows involve setting properties that force the element to have layout. In fact, if you come across an IE/Win bug, one of the first things you can do is try applying rules that force layout to see if that fixes the problem.

If you would like to learn more about IE’s internal hasLayout property, I recommend reading “On Having Layout” at http://tinyurl.com/acg78.

Common bugs and their fixes

One of the greatest skills any CSS developer can have is the ability to spot common browsers bugs. By knowing the various elements that conspire to cause these bugs, you can spot and fix them before they ever become a problem.

Double-margin float bug

One of the most common and easy-to-spot bugs is the double-margin float bug in IE 6 and below. As the name suggests, this Windows bug doubles the margins on any floated elements (see Figure below).

Figure Above: Demonstration of IE/Win’s double-margin float bug

This bug is easily fixed by setting the display property of the element to inline. As the element is floated, setting the display property to inline won’t actually affect the display characteristics. However, it does seem to stop IE 6 and below on Windows from doubling all of the margins. This is such a simple bug to spot and fix: every time you float an element with horizontal margins, you should automatically set the display property to inline.

Three-pixel text jog bug

Another very common IE 5-6/Win bug is the 3-pixel text jog bug. This bug manifests itself when you have text adjacent to a floated element. For instance, say you had an element floated left and you don’t want the text in the adjacent paragraph to wrap around the float.

You would do this by applying a left margin to the paragraph, the same width as the image:

.myFloat { float: left; width: 200px; }
p { margin-left: 200px; }

When you do this, a mysterious 3-pixel gap appears between the text and the floated element. As soon as the floated element stops, the 3-pixel gap disappears (see Figure Below).

Figure Above: Demonstration of the IE 5-6/Win’s 3-pixel text jog bug

Fixing this bug requires a two-pronged attack. First, the element containing the text is given an arbitrary height. This forces the element to have layout, which seemingly removes the text jog. Because IE 6 and below on Windows treats height like min-height, setting a tiny height has no effect on the actual dimensions of the element in that browser. However, it will affect other browsers, so the Holly hack is used to hide this rule from everything other than IE 6 and below on Windows:

/* Hide from IE5-Mac. Only IE-Win sees this. */
* html p { height: 1%; }
/* End hide from IE5/Mac */

Unfotunately, doing this causes another problem. As you learned earlier, elements with layout are constrained to a rectangular shape and appear next to floated elements rather than underneath them. The addition of 200 pixels of padding actually creates a 200-pixel gap between the floated element and the paragraph in IE 5-6/Win. To avoid this gap, you need to reset the margin on IE 5-6/Win back to zero:

/* Hide from IE5-Mac. Only IE-Win sees this. */
* html p { height: 1%; margin-left: 0; }
/* End hide from IE5/Mac */

The text jog is fixed, but another 3-pixel gap has now appeared, this time on the floated image. To remove this gap, you need to set a negative 3-pixel right margin on the float:

/* Hide from IE5-Mac. Only IE-Win sees this. */
* html p { height: 1%; margin-left: 0; }
* html .myFloat { margin-right: -3px; }
/* End hide from IE5/Mac */

This will fix the problem if the floated element is anything other than an image. However, if the floated element is an image, there is one last problem to solve. IE 5.x/Win adds a 3-pixel gap to both the left and the right of the image, whereas IE 6 leaves the image’s margins untouched. As such, another hack is required to remove the 3-pixel gap from IE 5.x/Win only:

/* Hide from IE5-Mac. Only IE-Win sees this. */
* html p { height: 1%; margin-left: 0; }
* html img.myFloat { margin: 0 -3px; margin: 0; }
/* End hide from IE5/Mac */

This solves the problem, but in a really nasty and complicated way. As such, if possible you would be better off splitting these rules up into separate, browser-specific stylesheets. If you did this, you could have one stylesheet for IE 5.x on Windows:

p { height: 1%; margin-left: 0; }
img.myFloat { margin: 0 -3px; }

And another for IE 6:

p { height: 1%; margin-left: 0; }
img.myFloat { margin: 0; }

IE 6 peek-a-boo bug

Another strange and infuriating bug is IE 6’s peek-a-boo bug, so called because under certain conditions text will seem to disappear, only to reappear when the page is reloaded. This happens when there is a floated element followed by some nonfloated elements and then a clearing element, all contained within a parent element that has a background color or image set. If the clearing element touches the floated element, the nonfloated elements in-between seem to disappear behind the parent element’s background color or image, only to reappear when the page is refreshed (see Figure Below).

Figure Above: Demonstration of IE 6’s peek-a-boo bug

Luckily, there are a number of ways you can combat this bug. The easiest way is probably to remove the background color or image on the parent element. However, this is often not practical. Another way is to stop the clearing element from touching the floated element. The bug doesn’t seem to manifest itself if the container element has specific dimensions applied. The bug also doesn’t manifest itself if the container is given a line height. Lastly, setting the position property of the float and the container to relative also seems to alleviate the problem.

Absolute positioning in a relative container

The last major browser bug I am going to cover involves absolutely positioned elements within a relatively positioned container. You learned in earlier chapters how useful nesting an absolutely positioned element in a relative container can be. However, IE 6 and below has a number of bugs when you use this technique.

These bugs arise from the fact that relatively positioned elements don’t gain IE/Win’s internal hasLayout property. As such, they don’t create a new positioning context and all of the positioned elements get positioned relative to the viewport instead (see Figure Below).

To get IE 6 and below on Windows to behave correctly, you need to force the relatively positioned container to have layout. One way to do this is to explicitly set a width and height on the container. However, you will often want to use this technique when you don’t know the width and height of the container, or when you want one or both of these properties to be flexible.

Instead, you can use the Holly hack to supply an arbitrary height to the container. This will give the container layout, but because elements in IE 6 and below incorrectly expand to fit their contents, the actual height won’t be affected.

/* Hides from IE-Mac */ * html .container { height: 1%; } /* End hide from IE-Mac */

Stop picking on Internet Explorer

Internet Explorer isn’t the only buggy browser around, so you may wonder why I have been focusing my attentions on IE bugs. Don’t worry, it’s not another case of Microsoft bashing; there are good reasons for this focus.

First, IE has by far the biggest browser market share. With so many copies in circulation, IE bugs tend to get found and documented pretty quickly. When a major CSS bug gets discovered in IE, scores of developers will be on the case trying to find a fix or a workaround. Because of this popularity, there are more well-documented bugs and fixes for IE than any other browser.

The other major issue is the pace of development. Browsers such as Firefox, Safari, and Opera are constantly being updated, with new builds appearing with remarkable frequency. Almost as soon as a bug is discovered, it is fixed and a new version of the browser released. Because of this, any Firefox or Safari bug I talk about now will probably have been fixed by the next revision.

This pace of development is excellent, but it does have its own problems. Rather than having two or three versions of a browser to deal with, you may have 20 or 30. You can never be sure if your users have the latest version, and this makes testing extremely difficult. IE, on the other hand, didn’t see a major revision for about 5 years. As such, there has been much more time for bugs to surface and much more impetus to find a fix.

Luckily, IE 7 promises to be a much more compliant browser. Many of the better known IE bugs have been addressed, along with increased support for advanced CSS 2.1 selectors such as the child and attribute selectors. As with all browsers, new bugs will surface, and IE 7 will be far from perfect. However, the faster people can be convinced to upgrade to modern browsers such as IE 7 and Firefox, the quicker older browsers such as IE 5.0 can be retired.

In the interim, it is worth exploring Dean Edwards’ excellent IE 7 patch. This series of JavaScript files aims to bring IE 5-6/Win up to speed with IE 7. This includes improved selector implementation and numerous bug fixes. For more information about this patch, visit http://dean.edwards.name/IE7/.

Summary

In this chapter, you have learned some important techniques for tracking down and squashing CSS bugs. You have learned about IE on Windows internal hasLayout property and how this is the root of many IE/Win browser bugs. Finally, you have learned about some of the most common browser bugs and how to fix them.

Next you will see how all of this information can be put together, through two stunning case studies created by two of the best CSS designers and developers of our time.

相关文章:

• IE Haslayout 详解
• CSS XHTML 相关资源整合
• XHTML CSS Tools collection
• Safari/Chorme/Webkit-based Browsers CSS hack redux
• 拥有布局 IE haslayout

]]> http://adamghost.com/2009/03/ie-has-layout-and-bugs/feed/ 0 http://adamghost.com/2009/03/ie-has-layout-and-bugs-zh/ http://adamghost.com/2009/03/ie-has-layout-and-bugs-zh/#comments Sun, 29 Mar 2009 17:09:21 +0000 不一样的蚊子 http://adamghost.com/?p=366 找们那知道浏览器有bug，而且Windows上的lE的bug 似乎比太多数浏览器都多。IE/Win的衣现与其他浏览器不同的原因之一是，显示引擎使用一个称为布局(layout)的内部概念。因为布均是一个专门针对显示引擎内部工作方式的概念，所以一般悄况下不需要了解它。但是，布局问题是许多IE/Win显示bug的根源，所以理解这个概念以及它如何影响CSS是有捂助的。

什么是布局

Windows 上的IE 使用布局概念来控制元素的尺寸和定位。那些称为拥有布局(have layout)的元素负责本身及其子元素的尺寸和定位。如果一个元旦在没有拥有布局，那么它的尺寸和位置由最近的拥有布局的祖先元素控制。

IE 显示引擎利用布局概念减少它的处理开销。在理想悄况下，所有元素都控制自己的尺寸和定位。但是，这会在IE中导致很大的性能问题。因此，IE/Win 开发团队决定只将布局应用于实际需要它的那些元素，这样就可以充分地减少性能开销。

在默认情况下拥有布局的元素包括:

• body
• 标准模式中的 html
• table
• tr, td
• img
• hr
• input, select, textarea, button
• iframe, embed, object, applet
• marquee

布局概念是Windows 上的I E 特有的，而且它不是CS S 属性.尽管某些CSS 属性会使元ffi拥有布局，但是在CSS 巾无法显式地设宣布局.可以使用JavaScript 函数hasLayout 查看一个元亲是否拥有布局.如果元素拥有布局，这个函数就返回true ; 否则返回falseo hasLayout 是一个只读属性，所以无法使用JavaScript 选行设置.

设宜以下CSS 属性会自动地使元亲拥有布局·

• position: absolute
• float: left or right
• display: inline-block
• width: any value
• height: any value
• zoom: any value (Microsoft property—doesn’t validate)
• writing-mode: tb-rl (Microsoft property—doesn’t validate)

布局有什么效果?

布局是许多IElWin 显示bug 的根源。例如， 如果一个文本段落靠谷一个浮动元索，那么期望文本围绕这个元索。但是，在Windows 上的1E 6 和更低版本巾，如果段落拥有布局(例如，由于设置了高度).那么它就被限制为矩形，因此阻止文本国绕浮动元素〈见图9-5).

Figure Above: 期望文本围绕相邻的浮动元素，但是，在IE/Win上，如果文本元素拥有布局，就不会这样显示。

这会导致浮动布间的各种问题更糟的是，许多人使用IE 作为主浏览器，他们会俯误地认为这才是正确的表现，在其他浏览器以不同方式处理泞-动元素时，他们反而会这必不解.

另-个问题涉及拥有布局的元素如何确定自己的尺，如果元亲的内容变得比元素本身大，那么期望元素流出到元素外.但是，在Windows 上的IE 6 和更低版本中，拥有布局的元素会销误地扩展以便适应内容的尺寸(见圈9-6).

Figure Above: 拥有布局的错误的扩展以便适应内容

这意味IE/Win中的width 实际上更像min-width. 这种行为也是在IE/Win中许多浮动布局被破坏的原因。当浮动框的内容错误地迫使框的宽度增加时，框对于可用空间来说太大了，因此下降到其他浮动元素在下面.

其他问题包括:

• 拥有布局的元素不进行收缩。
• 布局元亲对浮动进行自动消理。
• 相对定位的元素不获得布局。
• 在拥有布局的元素之间空白地不叠加。
• 在不拥有布局的块级链接上，单击区域只覆盖文本。

在下一节中，我们将讨论一些最常见的浏览器bug. 你会注意到对于Windows 上的IE的许多修复方法都涉及通过设置属性迫使元素拥有布局。实际上，如果遇到一个IE/Wi n bug，首先应该做的事情之一就是尝试通过应用规则迫使元崇拥有布局。看看这是否可以修复问题。

如果希忘进一步了解IE的内部hasLayout属性，我建议阅读http://tinyurl.com/acg78上的”On Having Layout”。【我的翻译文章在这里IE Haslayout 详解】

常见bug及其修复方法

CSS 开发人员最重要的技能之一是发现常见浏览器bug的能力。通过了解导致这些bug 的各种元索，可以在它们造成问题之前发现并且修复它们。

双空白边浮动bug

最常见且最容易发现的bug 之一是IE6和更低版本中的双空白边浮动bug。顾名思义，这个Windows bug使任何浮动元素上的空白边加倍(见图9-7)。

Figure Above: IE/Win 的双空白浮动bug示意阁

这个bug 很容易修复，将元素的display 属性设置为inline 就行了.因为元素是浮动的，将display 属性设置为inline 实际上不会影响显示方式。但是，这似乎会阻止Windows 上的IE6和更低版本将所有空白地加倍。这是一个非常容易发现和修复的bug : 每当对具有水平空白边的元素进行浮动时，都应该很自然地将display 属性设置为inline。

3像素文本偏移bug

另一个非常常见的I E 5-61Win bug 是3像素文本偏移bug。当文本与二个浮动元示相邻时，这个bug 就会表现出来。例如，假设将-个元素向左浮动，并且不希望相邻段落中的文本围绕浮动元素。你可能会在段落上应用一个左空白边，其宽度等于浮动元素的宽度:

.myFloat { float: left; width: 200px; }
p { margin-left: 200px; }

如果这么做，在文本和浮动元素之间就会出现一个莫名其妙的3像素间隙。(见图9-8) 。

Figure Above: IE 5-6/Win 的3像素文本偏移bug示意图

修复这个bug 需要双管齐下。首先，给包含文本的元素设置任意的高度。这会迫使元素拥有布局，这在表面上会消除文本偏移。因为Windows 上的IE6和更低版本将height作为min-height那样对待，所以设置一个小的高度并不会影响元素在这些浏览器巾的实际尺寸。但是，这会影响其他浏览器，所以要使用Holly招数对除了Windows 上的IE6 和更低版本之外的所有其他浏览器隐藏这个规则，

/* Hide from IE5-Mac. Only IE-Win sees this. \*/
* html p { height: 1%; }
/* End hide from IE5/Mac */

不幸的是，这么做会导致另一个问题。正如在前面学到的，拥有布局的元素被限制为矩形的，并且出现在浮动元索的旁边而不是它们的下面。添加200像素的空白边实际上会在IE 5-6/Win 中在浮动元素和段落之间产生200像素的间隙。为了边免这个问隙，需要将IE 5-6/Win 上的空白边重新设置为零:

/* Hide from IE5-Mac. Only IE-Win sees this. \*/
* html p { height: 1%; margin-left: 0; }
/* End hide from IE5/Mac */

文本偏移被修复了，但是现在另一个3像亲间隙出现了，这一次是在浮动元素上。为了去掉这个问隙，需要在浮动元素上设置一个负值的3像素右空白边：

/* Hide from IE5-Mac. Only IE-Win sees this. \*/
* html p { height: 1%; margin-left: 0; }
* html .myFloat { margin-right: -3px; }
/* End hide from IE5/Mac */

如果浮动元素是除了图像之外的任何其他东西，那么这个问题己经修复了。但是，如果浮动元旦在是图像，那么还有放后一个问题需要解决。 IE 5.x/Win在图像的左右都添加3像亲的间隙。而IE6不改变图像的空白边。因此，需要用另一个招术在IE 5.x/Win 上去掉3 像素的问隙:

/* Hide from IE5-Mac. Only IE-Win sees this. \*/
* html p { height: 1%; margin-left: 0; }
* html img.myFloat { margin: 0 -3px; ma\rgin: 0; }
/* End hide from IE5/Mac */

这会解决问题，但是采用的方式很难看而且太复杂。因此，如果可能的话，最好将这些规则分别放进单独的浏览器特定的样式表中。如果这样做，用于Windows 上的lE 5.x的样式表如下：

p { height: 1%; margin-left: 0; }
img.myFloat { margin: 0 -3px; }

用于IE 6的样式表如下:

p { height: 1%; margin-left: 0; }
img.myFloat { margin: 0; }

IE 6躲躲猫bug

另一个奇怪而且很烦人的 bug 是IE6 的躲躲猫(peek-a-boo) bug，之所以起这个名称是因为在某些条件下文本看起来消失了，只有在前新装载页面时才再度出现。出现这个bug 的条件是:一个浮动元素后面跟着一些非浮动元素，然后是一个清理元素，所有这些元素都包含在一个设置了背景颜色或阅像的父元束中。如果清理元素碰到了浮动元素，那么中间的作浮动元素看起来消失了，隐藏到了父元素的背景颜色或图像后面，只有在刷新页面时才重新出现(见图9-10)。

Figure Above:IE 6的躲躲猫bug示意图

相对容器中的绝对定位

我要讨论的段后一个主要浏览器bug涉及相对定位容器中的绝对定位元素。在前面的章节中你学到将绝对定位的元素嵌套在相对容器中是多么有用。但是，IE 6和更低版本在使用这种技术时有许多bug。

这些bug 的原因在于相对定位的元素没有获得IE/Win 的内部hasLayout 属性。因此，它们不创建新的定位上下文，所有绝对定位元素相对于窗口进行定位(见图9-11)。

Figure Above:IE5.x对相对容器中的绝对定位元素的定位方式不正确

为了使Windows 上的IE 6和更低版本的表现正确。需要迫使相对应位的容器拥有布局。一种方法是在容器上显式地设置width 和height。但是，常常希望在不知道容器的width 和height的况下，或者在需要这些属性保持灵活的情况下使用这种技术。

可以使用Holly 招数为容器提供一个的高度。这会让容器拥有布局。但是因为IE 6和更低版本中的元素会不正确地扩展以适应它们的内容，所以设置小的高度不会影响实际高度。

/* Hides from IE-Mac \*/
* html .container { height: 1%; }
/* End hide from IE-Mac */

停止对IE 的批评

IE 并不足惟一一种有bug 的浏览器，所以你可能会奇怪我为什么只关注IE bug。 不必担心，我找并不是专门和微软过不去，这么做是有理由的。

首先， IE 目前占有最大的浏览器市场份额。因为有许多人在使用IE，IE bug 往往很快被发现而且很好地记录下来。当在IE中发现一个重大的CSS bug时，许多开发人员会尝试寻找修复方法或解决方案。由于IE的流行程度，被记录并修复的IE bug比其他任何浏览器都要多.

另一个主要问题是开发的节奏。Firefox、Safari和Opera等浏器不断地进行更新，新版本以非常高的频率出现。 bug 几乎一经发现就被修复了，并且发布浏览器的新版本.因此，现在讨论的任何Firefox或Safari bug 可能已经被下一个修订版修复了。

如此高的开发节奏确实很棒，但是也有自己的问题。开发人员要应付的浏览器版本不是两三个，而是20或30个。你无法确定用户是否使用最新的版本，这使测试变得极其困难。另一方面，IE差不多5年没有发布主要修订版了。因此，bug 有更多的时间可以暴露出来，开发人员也有更强的寻找修复方法的动力。

幸运的是，IE 7承诺将成为更符合标准的浏览器。许多著名的IE bug 已经被解决，而且对高级CSS 2.1 选择器（比如子选择器和属性选择器）的支持也在增加。与所有浏览器一样，新的bug也会出现，IE 7远不是完美的。但是，人们越快地升级到IE 7和Firefox 等现代浏览器，IE 5.0等老式浏览器就会越快地退役。

在这个过渡时期，可以考虑使用Dean Edwards 的IE 7 补丁。这是一系列JavaScript 文件，它们使IE 5-6/Win 能够接近IE 7的水平.这包括改进的选择器实现和许多bug 修复。关与这个补丁的更多信息，请访问http://dean.edwards.name/IE7/。

相关文章:

• IE Haslayout 详解
• CSS XHTML 相关资源整合
• XHTML CSS Tools collection
• Safari/Chorme/Webkit-based Browsers CSS hack redux
• Having “layout”

]]> http://adamghost.com/2009/03/ie-has-layout-and-bugs-zh/feed/ 9 http://adamghost.com/2008/12/ie-haslayout-%e8%af%a6%e8%a7%a3/ http://adamghost.com/2008/12/ie-haslayout-%e8%af%a6%e8%a7%a3/#comments Tue, 09 Dec 2008 19:21:20 +0000 不一样的蚊子 http://www.adamghost.com/?p=117 IE的haslayout是个很纠结的东西，掌握好CSS就得掌握好它。初学CSS时走了很多弯路，以下几篇文章在我的学习中起了很大的作用，希望能让大家受益。

此文是和老包共同弄的，参考了On have layout 。

另外两篇文章摘自CSS Mastery【精通CSS】，与此文相互补充，希望对大家有帮助

• Having “layout”
• 拥有布局 IE haslayout

拥有layout概述

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

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

微软的开发者们认为元素都应该可以拥有一个”属性(property)”(这是面向对象编程中的一个概念)，于是他们便使用了 hasLayout，这种渲染特性生效时也就是将 hasLayout 设成了 true 之时。了解hasLayout将对IE的臭虫会有更多深入的体会甚至解决方案。

拥有layout的定义

一个元素”得到 layout”，或者说一个元素”拥有 layout” 的时候，是指它的微软专有属性 hasLayout 为此被设为了 true 。一个”layout元素”可以是一个默认就拥有 layout 的元素或者是一个通过设置某些 CSS 属性得到 layout 的元素。
而”无layout元素”，是指 hasLayout 未被触发的元素，比如一个未设定宽高尺寸的干净 div 元素就可以做为一个”无layout祖先”。

给一个默认没有 layout 的元素赋予 layout 的方法包括设置可触发 hasLayout = true 的 CSS 属性。参考默认 layout 元素以及这些属性列表。没有办法设置 hasLayout = false ， 除非把一开始那些触发 hasLayout = true 的 CSS 属性去除或重置。

拥有layout的各种问题

Layout 在显示盒模型时有着不同寻常而且难以预料的效果，而且有时甚至会牵连到他们的子元素。

一个元素是否具有”layout”可能会引发如下的一些问题（包括但不限于）：

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

Layout 的由来

不同于标准属性，也不像某些浏览器的私有 CSS 属性，layout 无法通过某一个 CSS 声明直接设定 。也就是说没有”layout属性”这么一个东西，元素要么本身自动拥有 layout，要么借助一些 CSS 声明悄悄地获得 layout。

下列元素应该是默认具有 layout 的：

• <html>, <body>
• <table>, <tr>, <th>, <td>
• <img>
• <hr>
• <input>, <button>, <select>, <textarea>, <fieldset>, <legend>
• <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” 外的任意值
  IE专有属性。不过 zoom: 1 可以临时用做调试。
• writing-mode: tb-rl
  MS专有属性。
• overflow: hidden|scroll|auto
  在 IE7 中，overflow 也变成了一个 layout 触发器，这个属性在之前版本 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” 之外的任意值

有关内联级别元素

对于内联元素(可以是默认即为内联的比如 span 元素，也可以是 display: inline 的元素)

• width 和 height 只在 IE5.x 下和 IE6 或更新版本的 quirks 模式下触发 hasLayout 。而对于 IE6，如果浏览器运行于标准兼容模式下，内联元素会忽略 width 或 height 属性，所以设置 width 或 height 不能在此种情况下令该元素具有 layout。
• zoom 总是可以触发 hasLayout，但是在 IE5.0 中不支持。

具有”layout” 的元素如果同时也 display: inline ，那么它的行为就和标准中所说的 inline-block 很类似了：在段落中和普通文字一样在水平方向和连续排列，受 vertical-align 影响，并且大小可以根据内容自适应调整。这也可以解释为什么单单在 IE/Win 中内联元素可以包含块级元素而少出问题，因为在别的浏览器中 display: inline 就是内联，不像 IE/Win 一旦内联元素拥有 layout 还会变成 inline-block。

重置 hasLayout

在另一条规则中重设以下属性为默认值将重置(或撤销)hasLayout，如果没有其他属性再添加 hasLayout 的话：

• width, height (设为 “auto”)
• max-width, max-height (设为 “none”)(在 IE 7 中)
• position (设为 “static”)
• float (设为 “none”)
• overflow (设为 “visible”) (在 IE 7 中)
• zoom (设为 “normal”)
• writing-mode (从 “tb-rl” 设为 “lr-t)

display 属性的不同：当用”inline-block”设置了 haslayout = true 时，就算在一条独立的规则中覆盖这个属性为”block”或”inline”，haslayout 这个标志位也不会被重置为 false。

把 mid-width, mid-height 设为它们的默认值”0″仍然会赋予 hasLayout，但是 IE 7 却可以接受一个不合法的属性”auto”来重置 hasLayout。

Technorati : css, haslayout, ie, web standard, zoom
Del.icio.us : css, haslayout, ie, web standard, zoom
Zooomr : css, haslayout, ie, web standard, zoom
Flickr : css, haslayout, ie, web standard, zoom

相关文章:

• IE调试环境中选择IE8+iedevelopbar的原因
• flash 在浏览器中大小
• Having “layout”
• 拥有布局 IE haslayout
• (X)HTML Strict 下的嵌套规则

]]> http://adamghost.com/2008/12/ie-haslayout-%e8%af%a6%e8%a7%a3/feed/ 12