对于IE浏览器中的HasLayout的认识

最新推荐文章于 2022-03-30 20:09:33 发布

Philo_you

最新推荐文章于 2022-03-30 20:09:33 发布

阅读量673

点赞数

分类专栏： CSS 文章标签： css html ie6 layout 布局

本文链接：https://blog.csdn.net/philo_you/article/details/30294973

版权

CSS 专栏收录该内容

0 篇文章 0 订阅

订阅专栏

什么是“HasLayout”，它很重要么？

通过在元素(修复尺寸bug，Holly hack)上添加一个“layout”（一个IE内部的数据结构），就可以解决IE浏览器中的几个bug。大多数的使用者并没有注意到为一个元素赋予了“layout”后会产生的影响，这篇文章会阐述当元素拥有“layout”时会发生什么，以及能产生什么样的影响。

在开始之前，先说明元素的两种集合：

1.通过父元素获取自身的尺寸来组织自身内容的元素。

2.依靠自身来定义自己的尺寸和安排内容的元素。

通常，在IE浏览器中的动态HTML引擎的渲染下的元素，不会对自身的尺寸安排负责。一个div或是p元素也许在源代码的顺序和文档流中具有一定的位置，但是它们的内容该如何组织，是通过离它们最近的具有一个布局的祖先元素来规定的（多数是来自body）。这些元素依靠祖先元素的布局来为自己定义繁琐的尺寸信息。

小记：对一个元素的尺寸和定位负责的或许是一个祖先元素，并不仅仅是那个元素较近的父元素。每个元素并不具有自己的布局的最主要的好处是体现在表现和简洁方面。

那么，拥有了一个布局（layout）意味着什么？

说简单些，拥有了一个布局的元素会对自己的尺寸和定位负责，也可能对任何子元素的尺寸和定位负责（如果一个子元素有了自己的布局，它会对自己和后代元素的尺寸进行定义，但是原始的布局使子元素获得了定位）。

一些元素具有一个“固定”的尺寸，要不然的话就会有特殊的尺寸限制。它们总是具有布局的—比如说： buttons, images, inputs, selects,以及选择框元素均拥有浏览器默认的尺寸，即使width和height没有设置。
有时候，像一个div或是一个span通常不需要一个布局信息，为了支持layout这个属性，也许会有一些特殊的属性来应用到这些元素上使其具有一个布局，比如说，元素必须具有布局才能够设置其滚动条。

一旦一个布局被应用了，hasLayout的属性值就处于设置状态，这个属性值就为true。

拥有一个布局为什么重要？

这会使一个元素的形状成为矩形。这将意味着那个元素里的内容不会再流动到其他盒子模型的周围，例如，在IE的渲染引擎里，浮动的元素不会对拥有布局边界的元素造成影响。
具有布局的元素也许会建立一个新的块级形式的上下文。
由于布局是具有缓存信息的额外对象，也会参与到尺寸和定位中的算法，拥有一个布局可是有代价的——它会增加内存的使用率，还会降低样式表现的质量。
同时还会有对自适应尺寸元素的副作用：一个拥有布局的元素不能够减小自身的大小来适应它的子元素，比如，一个绝对定位的盒子包围着一个具有布局的元素，那么这个绝对定位的元素不会改变自己的尺寸来适应具有布局元素的子代元素。
一个矩形布局元素会根据它的内容的增加来扩展自己的尺寸（这是IE6 中的 height bug）。

许多人都在使用布局来解决IE6中的bugs，尤其是在相对定位的元素上。然而，相对定位的元素并不需要一个布局，并且拥有布局的副作用会在相对定位元素有了布局时造成问题。

哪些元素总是拥有一个布局？

大致说来，拥有自己的范围，需要维护特定的信息和功能性的定位、并且将自己的内容渲染到自身的范围中的任何元素，总是拥有一个布局的。

Images
Tables, TableRows, TableCells
HR
Input 元素: text, button, file, select
选择框
Framesets, Frames
Objects, applets, plugins
绝对定位元素
浮动元素
Inline-block元素
Filters (rotation, dropshadow, etc.)
Body (与严格型的HTML元素一样)

哪些元素可以获得一个布局呢？

严格模式下，定义了宽度和高度的块级元素
兼容模式下，任何具有宽度或高度的元素
设置了Zoom属性的元素
处于文档编辑模式下的元素
Elements that host to a viewlinked behavior（不知该怎么翻译了）
布局流不同于父布局流

有关布局hacks的例子

“HasLayout”的影响

场景 1: 浮动

让我们看看下面的标记：

The quick brown fox jumped over the lazy dog's back.

</span>

我们要看到的：

你注意到，文本流畅地流动在向左浮动的div，正如我们做期望的那样
边框是为了表明围绕着span的盒子的轮廓

那么当我们把布局设置给包围文本的span元素时，会发生什么？

<style>

.gainlayout {zoom: 1;}

</style>

被设置的布局使得span元素成了一个矩形的盒子
文本不会再浮动在div的周围了，这是非常重要的，因为它将会破坏所期望的文本的布局表现（想象一下你把布局属性赋给一个p标签）

场景 2 ：自适应大小

<div>父元素是绝对定位的元素</div>

</div>

我们要看到的：

第一个绝对定位的div与容纳它的块级元素有关（在这里的情形就是视口），并且它脱离了文档流
具有红色背景的div收缩了起来,包围了“父元素是绝对定位的元素”，这是由于包围“父元素是绝对定位的元素”的div的布局是由其绝对定位的父元素来决定的。

那么当我们把布局设置给包围“父元素是绝对定位的元素”的div元素时，会发生什么？

<style>

.gainlayout {zoom: 1;}

</style>

<div class="gainlayout">父元素是绝对定位的元素</div>

</div>

场景 3 ：Position:relative

让我们来看一个例子，“hasLayout”会以bug的方式展现出来：

</div>

我们或许会想，IE会这样表现：

一条折叠了的4像素宽的蓝线（折叠是因为它的子元素被移除了文档流）
一个浮动的有红色边框的盒子会包含一个有绿色边框的图片

应该是这个样子：

但是IE6会给你个惊喜：

那么，刚刚发生了什么呢？

由于图片是相对定位的，它会依赖于父元素的布局来决定自己会被定位在哪里
图片的父元素的布局是一个向左浮动的div，已经有了“hasLayout”
IE6的相对定位度量代码是非常脆弱的（这是一个bug，在IE7中被修复），而且它的父元素布局会在将度量信息传递给图片时会产生错误。

小记：你也许已经注意到折叠的蓝线并没有从它本该起始的位置开始延伸。This is the first draw back we will notice of "Has Layout"(这句不知怎么翻译了). 浮动的元素形成了自己的布局盒子，并且不会被蓝色边框的div所侵占，在这样的情形下，就是一个IE的内部bug。

通常情况下，我们会给相应的元素添加一个布局来解决这样的问题：

<style>

.gainlayout {zoom: 1;}

</style>

结果会是这样：

好的是：

你的图片会在它该停止的地方停下来（顶级的布局会将正确的度量信息赋予给浮动的元素和图片）

不好的是：

拥有了布局的div现在具有了不想要的副作用

在具有蓝色边框的div就像它应该呈现的那样，不会再折叠了，但是它却形成了一个布局盒子围绕在浮动的div和图片周围
任何流动在浮动div周围的文本，现在将会被封闭住了
在这样的情形下，对于表现性能方面的冲击是次要的，但是当你在页面中放上50个这样的情形的话，你就会明白了

在这个场景中，你不用做的太多（或许可以移除掉没有必要的position：relative）。我们并不是尝试着要去建议大家不去使用布局来解决IE中的bug，而是尽力说清楚在你使用布局的时候会产生什么样的影响。理想的情况下，所有的问题都要被修复，如果不在IE7中，那就会在更新的版本中了。

再说一些

我已经试图解释了一点“hasLayout”的内部机理，还有它的副作用。我也列出了那些元素拥有内建的布局属性，以及什么时候平常的元素会获得布局。最后，我讨论了拥有一个布局所产生的影响，还有给出了在赋予一个元素布局属性的时候会发生什么。

理想情况下，使用者没有什么必要对这样一个属性了解多少，因为它主要是用在IE的内部来实现CSS定位的。然而，对于一些IE6中尺寸大小方面的bug，它是一个不错的解决办法。这个属性并不与CSS的规格相冲突，因为它就是用来在内部实现相应的规范的（在可以容许存在的bug里）。将这一点记在心中，我还想列举出一些在拥有布局的时候所产生的微影响。

说明一下：

这篇文档来自一篇英语文档

我在尝试着把它翻译出来，其中会有一些让人难以理解的地方，我翻译的也不是很好，我也在努力的寻找和探索中，十分愿意和大家一起解决IE中的各种bug，一起收获，一起努力