寂寞的hasLayout

hasLayout 是IE特有的一個屬性，它很寂寞，正因為寂寞所以搞出很多莫名其妙的事情，很多的ie下的css bug都與其息息相關。查讀了很多網上關于haslayout相關的文章，其中“haslayout-Sinab-搜狐博客”，鏈接地址:http://sinab365.blog.sohu.com/107239414.html這里的文章概括的比較全面，以及涉及的知識也比較豐富。

zoom: 1; 可以讓 IE5.5+ 的任何元素(包括內聯元素)獲得 layout，但是在 IE5.0 中無效。
沒有其他附帶效果(內聯元素會變成 inline-block，這個當然)。
如果需要通過驗證，應該用條件注釋將 zoom 隱藏起來。

其實當我們考慮到“向后兼容”時是很自相矛盾的，我們強烈建議頁面設計者回過頭看一下自己頁面中用的到的明顯的或是不明顯的“hacks”，并用條件注釋針對不同瀏覽器重新處理以保萬無一失。



關于IE Mac 的小問題


IE Mac 和 windows 下的 IE 是完全不同的兩個東西，它們各自擁有自己的渲染引擎，IE Mac 就全然不知“hasLayout”(或contenteditable)所謂何物。相比之下 IE Mac 的渲染引擎要更標準兼容一點，比如 height 就是被當作 height 處理，沒有別的效果。因此針對“hasLayout”的 hacks 和別的解決方法(特別是通過使用 height 或 width 屬性的)往往對 IE Mac 來說是有害的，所以需要對其隱藏。更多的關于 IE Mac 相關的問題可以在 IE Mac, bugs and oddities pages http://www.l-c-n.com/IE5tests/找到。


MSDN 文檔


MSDN 中涉及到 hasLayout 這個 MS 屬性的地方寥寥無幾，而具體解釋 layout 和 IE 渲染模型之間關系的則少之又少。
在IE4的時候，除了未經絕對定位也未指定寬高的內聯元素，幾乎所有元素都有某種 layout(MSDN)。http://msdn.microsoft.com/worksh ... mentandlocation.asp在這種早期的layout概念中，像 border, margin, padding 這些屬性被稱作“layout屬性”，它們是不能應用到一個簡單的內聯元素上的。換句話說，“擁有layout”就可以粗略理解成：“可以擁有這幾個屬性”。
MSDN 上仍然使用 layout 屬性這種說法， 只是含義變了，它們和擁有 layout 的元素已經沒有什么關系了。在 IE5.5 中方才引入了 MS 的這個專有屬性 hasLayout，http://msdn.microsoft.com/worksh ... rties/haslayout.asp也只是某種內部的標志位而已。
在 IE5.5 中，MSHTML Editing Platform(即可以通過設置來允許用戶實時編輯、拖動 layout 元素以及調整其尺寸等)的文檔中描述了三個和 layout 相關的重要特性：
如果一個 layout 元素中有內容，內容的排版布局將由它的邊界矩形框決定。
擁有 layout 的意思基本上就是表示某元素是一個矩形。
從內部來說，擁有 layout 意思就是一個元素將自己負責繪制其內部內容。

(Editing Platform) http://msdn.microsoft.com/librar ... mshtmleditplatf.asp

和 layout 自身相關的內部工作機制直到2005年8月才有相應文檔描述，當時由于 The Web Standards Project http://www.webstandards.org/和微軟的特別工作小組的原因，Markus Mielke [MSFT] 打開了深入討論的大門：
一般來說，在 Internet Explorer 的 DHTML 引擎中，元素是不對自己的位置安排負責的。雖然一個 div 或者一個 p 元素都在源碼中有一個位置，在文檔流有一個位置，但是它們的內容卻是由它們最近的一個 layout 祖先(經常是 body)控制安排的。這些元素依賴它們祖先的 layout 來為他們處理諸如決定大小尺寸和測量信息等諸多繁重的工作。

(HasLayout概述)http://msdn.microsoft.com/library/default.asp?url=/library/en-us/IETechCol/cols/dnexpie/expie20050831.asp


分析



我們的分析試圖解釋在已知案例下發生了什么事情，這種分析也應該可以作為未知案例下的指導。但我們這種試圖利用種種測試案例投石探路的黑箱測試方法，是注定無法消除黑箱的神秘感的——我們無法回答“為什么”的問題。我們只能去嘗試了解整個“hasLayout”模式的工作框架，以及它會怎樣影響網頁文檔的渲染。因此，最終我們只能提供一些指導方針(而且只能是指導方針，而不是絕對的解決方案)。
我們認為他們所指的是一個小窗體。一個 layout 元素的內部內容是完全獨立的，而且也無法影響其邊界外的任何內容。
而 MS 屬性 layout 只是某種標志位：一旦它被設定，這個元素就會擁有 layout“特性”，這包括體現在其自身以及其非 layout 孩子元素身上的特殊性能——比如浮動和層疊等。
這種獨立性也許正可以解釋為什么 layout 元素通常比較穩定，而且它們可以讓某些 bug 消失。這種情況的代價有二，一是偏離了標準，二是它沒有考慮到今后可能因此出現的 bug 和問題。
MS 的“頁面”模式，從符號學角度考慮，可以看做是由很多互不相關的小的區塊構成，而 HTML 和 W3C 的模式則認為“頁面”模式應該是敘述完備的，故事性的相關信息區塊構成的。



各種情況的詳細說明



清除浮動和自動擴展適應高度
浮動元素會被 layou 元素自動包含。這是很多新手經常遇到的問題：在 IE 下完成的頁面到了標準兼容瀏覽器下所有未清除的浮動元素都伸出了其包含容器之外。
Containing Floats http://www.complexspiral.com/publications/containing-floats
how to clear floats without structural markup http://positioniseverything.net/easyclearing.html

相反的情況：如果確實需要一個浮動元素伸出其包含容器，也就是自動包含不是想要的效果時，該怎么辦？你很可能也會遇到這種頭疼的問題，下面的深入討論就是一個例子：
acidic float tests http://www.satzansatz.de/cssd/acidicfloat.html

在IE中，一個浮動元素總是“隸屬于”它的 layout 包含容器。而后面的元素會受這個 layout 包含容器影響而不是這個浮動元素影響。
這個特性和IE6的那個自動擴展以適應內部內容寬度的特性，都可以看成是受這個規則影響的：“由它的邊界矩形框決定”。
更糟的問題：clear 無法影響其 layout 包含容器之外的 float 元素。如果依賴這個 bug 在 IE 中布局的頁面要轉到標準兼容瀏覽器中，只有全部重做。
IE 的自動包含浮動元素也是經常需要的效果，它在其他瀏覽器中也可以達到：參考我們的 “和 CSS 規范類似的地方” 這一部分來了解一下包含浮動元素的相關內容。
浮動元素旁邊的元素
當一個塊級元素緊跟在一個左浮動元素之后時，它應該——作為一個塊級元素——忽略這個浮動元素，而它的內容則應該因這個浮動元素而移位：一個緊跟在左浮動元素后的塊級元素內的文字內容，應該沿著浮動元素的右邊順序排列并會（如果它的長度超過浮動元素）繼續排列到浮動元素下方。但是如果這個塊級元素有 layout，比如由于某種原因被設置了寬度，那么這整個元素則會因浮動元素而移位，就好像它自己也是一個浮動元素一樣，因此其中的文字就不再環繞這個左浮動元素了（而會形成一個矩形區域，保持在它的右邊。）
在 IE5 中一個塊級元素的百分比寬度是基于浮動元素旁邊的剩余空間計算的，而在 IE6 中則是依照整個父塊級元素的可用空間計算的。所以在 IE6 中設置 width: 100% 會導致某種浮動元素旁邊的溢出現象，于是各種布局問題也會因此而來。
一些關于浮動塊旁邊的 hasLayout 塊的測試案例：
by using width http://dev.l-c-n.com/IEW2-bugs/float-layout.php
by using min-width (IE 7) and zoom (IE 6) http://dev.l-c-n.com/IEW2-bugs/float-adjecant.php

與此類似，和浮動元素相鄰的相對定位元素，它的位置偏移量應該參照的是父元素的補白(padding)邊緣(例如，left: 0; 應該將一個相對定位元素疊放于它前面的浮動元素之上)。在 IE6 中，偏移量 left: value; 是從浮動元素的右邊距(margin)邊緣開始算起的，這會因浮動元素所占的寬度變化導致水平方向的錯位(一個解決方法是用 margin-left 代替，但是也要注意如使用百分值時會有一些怪異問題)。
layout blocks with relative positioning adjacent to floated blocks http://dev.l-c-n.com/IEW2-bugs/float-layout2-rp.php

根據規范所述，浮動元素應該與其后的盒子交織在一起。而對于沒有交叉的二維空間中的矩形而言這是無法實現的。
如果誰真的需要向 IE 的這種不當行為屈服，那么如何讓標準兼容瀏覽器中的盒子也有類似行為——即類似于 layout 盒子會自動“收縮”而給其前置的浮動元素讓出空間的行為——就是一個問題了。我們給出的方法是跟著一個浮動元素創建一個新的塊級格式化范圍（block formatting context），這在我們的“和 CSS 規范類似的地方” 有討論。
可以(再次)訪問下面這個頁面：
three pixel text-jog http://positioniseverything.net/explorer/threepxtest.html

我們可以看到跟在一個浮動元素后的 layout 元素不會顯示這個3px間隙的 bug，因為浮動元素外圍的3px硬邊無法影響一個 layout 元素的內部內容，所以這個硬邊將整個 layout 元素右推了3px。好比一個防護罩，layout 可以保護其內部內容不受影響，但是浮動元素的力量卻將整個防護罩推了開來。
列表
無論是列表本身(ol, ul) 還是單個的列表元素(li)，擁有 layout 后都會影響列表的表現。不同版本 IE 的表現又有不同。最明顯的效果就體現在列表符號上(如果你的列表自定義了列表符號則不會受這個問題影響)。這些符號很可能是通過某種內部機制附到列表元素上的(通常是附著在它們外面)。不幸的是，由于是通過“內部機制”添加的，我們無法訪問它們也無法修正它們的錯誤表現。
最明顯的效果有：
列表獲得 layout 后，列表符號會消失或者被放置在不同的或者錯誤的位置。

有時它們又可以通過改變列表元素的邊距而重新出現。這看起來似乎是以下事實導致的結果：layout 元素會試圖裁掉超出其邊界的內部內容。
列表元素獲得 layout 之后，會有和上面一樣的問題出現，更多參考 (extra vertical space between list items)http://www.brunildo.org/test/IEWlispace.php

進一步又有一個問題就是(在有序列表中)任何具有 layout 的列表元素似乎都有自己獨立的計數器。比如我們有一個含五個列表元素的有序列表，只有第三個列表元素有 layout。我們會看到這樣：
1… 2… 1… 4… 5…
此外，如果一個有 layout 的列表元素跨行顯示時，列表符號會底部對齊(而不是按照預料的頂部對齊)。
以上某些問題還是無法解決的，所以如果需要列表符號的時候最好避免讓列表和列表元素獲得 layout。如果需要限定尺寸，最好給別的元素設定尺寸，比如給整個列表外面套一個元素并設定它的寬度，又或者比如給每個列表元素中的內容設定高度等等。
另一個IE中列表的常見問題出現在當某個 li 中的內容是一個 display: block 的錨點(anchor)時。在這種情況下，列表元素之間的空格將不會被忽略而且通常會顯示成額外的一行夾在每個 li 之間。一種避免這種豎直方向多余空白的解決方法是賦予這些錨點 layout。這樣還有一個好處就是可以讓整個錨點的矩形區域都可以響應鼠標點擊。
表格
table 總是有 layout 的，它總表現為一個已定義寬度的對象。在IE6中，table-layout: fixed http://msdn.microsoft.com/worksh ... ies/tablelayout.asp通常和一個寬度設為100%的表格相同，同時這也會帶來很多問題(一些計算方面的錯誤)。另外在IE5.5和IE6的quirks模式下還有一些別的需要注意的情況。http://dev.l-c-n.com/tables_2/
相對定位元素(r.p.)
注意，由于 position: relative 并不觸發 hasLayout，所以很多諸如內容消失或錯位的渲染錯誤就會因此而起。這些現象可能會在刷新頁面、調整窗口大小、滾動頁面、選中內容等情況下出現。原因是 IE 在據這個屬性對元素做偏移處理時，卻似乎忘了發出信號讓其 layout 孩子元素進行“重繪”(而如果是一個layout元素，那么在其重繪事件的信號鏈中，這個傳給其孩子的信號是會正常發出的)。
r.p. parent and disappearing floated child http://www.satzansatz.de/cssd/rpfloat.html
disappearing list-background bug http://positioniseverything.net/explorer/ie-listbug.html

以上是一些相關問題的描述。作為經驗之談，相對定位一個元素時最好給予其 layout。再有，我們也需要檢查擁有這種結構的父元素是否也需要 layout 或者position: relative亦或二者都需要，如果涉及到浮動元素這點就十分重要。
絕對定位元素(a.p.)：
包含區塊，什么是包含區塊？
理解 CSS 的包含區塊概念很重要，它回答了絕對定位元素是相對哪里定位的問題：包含區塊決定了偏移起點，包含區塊定義了百分比長度的計算參考。
對于絕對定位元素，包含區塊是由其最近的定位祖先決定的。如果其祖先都沒有被定位，那么就使用初始包含區塊 html。
通常情況下我們會用 position: relative 來設定任意包含區塊。這就是說，我們可以讓一個絕對定位元素所參考的原點和長度等不依賴于元素的排列順序，這可以滿足諸如“內容優先”這種可訪問性概念的需要，也可以給復雜的浮動布局帶來方便。
但是由于 layout 概念的存在，這種設計理念的效果在IE中就要打個問號了：因為在IE中絕對定位只有當其包含元素擁有 layout 時才會計算正確，而且絕對定位元素的百分比寬度參考也搞錯了對象。這里 IE5 和 IE6 的行為不同但都有問題。IE7b2 的行為就要好很多，雖然有些小地方還是有錯誤。總之盡可能的讓絕對元素的包含區塊擁有 layout，而且盡量讓其就是絕對定位元素的父級元素（也就是說這個包換元素和絕對定位元素之間沒有絕對定位元素的別的祖先了）。
假設一個無 layout 的父元素被相對定位了——我們就得給它賦予 layout 才能使偏移量起作用：
Absolutely Buggy II http://www.positioniseverything.net/abs_relbugs.html

假設一個未定位的父元素需要特定尺寸，而且頁面設計是基于百分比寬度的——我們就可以放棄這個想法了，因為瀏覽器支持不佳：
absolutely positioned element and percentage width http://www.satzansatz.de/cssd/tmp/apboxpercentagewidth.html
濾鏡
MS專有的濾鏡屬性 filter http://msdn.microsoft.com/workshop/author/filter/filters.asp是只適用于 layout 元素的。有些濾鏡擴展了對象的邊界。它們會顯示出自身特有的缺陷。http://www.satzansatz.de/cssd/tmp/alphatransparency.html
對已渲染元素的重排(re-flow)
當所有元素都已渲染完成時，如果有一個因鼠標經過而引起的變化產生(比如某個鏈接的 background 有變化)，IE會對其 layout 包含區塊進行重排。有時一些元素就會因此被排到了新的位置，因為當這個鼠標經過發生時，IE已經知道了所有相關元素的寬度、偏移量等數據了。這在文檔首次載入時則不會發生，那時由于自動擴張的特性，寬度還無法確定。這種情況會導致在鼠標經過時頁面出現跳變。
Jump on :hover http://www.satzansatz.de/cssd/pseudocss.html#hoverjump
quirky percentages: the reflow http://www.positioniseverything.net/explorer/percentages.html

這些和重排問題相關的 bug 會給百分比邊距和補白使用較多的流動布局帶來不少麻煩。
背景原點
MS專有的這個 hasLayout 還會影響背景的定位和擴展。比如，根據 CSS 規范，http://www.w3.org/TR/CSS21/colors.html#q2background-position: 0 0 應該指元素的“補白邊緣(padding edge)”。而在 IE/Win 下，如果 hasLayout = false 則指的是“邊框邊緣(border edge)”，當 hasLayout=true 時指的才是補白邊緣：
Background, Border, hasLayout http://www.brunildo.org/test/BackgroundBorderLayout.html

邊距重疊
hasLayout 會影響一個盒子和其子孫的邊距重疊。根據規范，一個盒子如果沒有上補白和上邊框，那么它的上邊距應該和其文檔流中的第一個孩子元素的上邊距重疊：
Collapsing Margins http://www.w3.org/TR/CSS21/box.html#collapsing-margins
Uncollapsing Margins http://complexspiral.com/publications/uncollapsing-margins

在 IE/Win 中如果這個盒子有 layout 那么這種現象就不會發生了：似乎擁有 layout 會阻止其孩子的邊距伸出包含容器之外。此外當 hasLayout = true 時，不論包含容器還是孩子元素，都會有邊距計算錯誤的問題出現。
Margin collapsing and hasLayout http://www.brunildo.org/test/IEMarginCollapseLayout.html

塊級別的鏈接
hasLayout 會影響一個塊級別鏈接的鼠標響應區域(可點擊區域)。通常 hasLayout = false 時只有文字覆蓋區域才能響應。而 hasLayout = true 則整個塊狀區域都可響應。添加了 onclick/onmouseover 等事件的任意塊級元素也有同樣的現象。
Block anchors and hasLayout http://www.brunildo.org/test/IEABlock1.html

在頁面內使用鍵盤瀏覽：探索中
當使用 tab 在頁面中瀏覽時，如果進入了一個頁內鏈接(in-page link)，那么接下來再按的 tab 鍵就不會正常繼續了：
hasLayout Property Characterizes IE6 Bug http://jimthatcher.com/news.htm#haslayout
Keyboard Navigation and Internet Explorer http://juicystudio.com/article/ie-keyboard-navigation.php
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”的塊級元素時，在絕大多數情況下，這個孩子元素的寬度會盡可能地擴展而與其中包含的內容無關，同時也阻止了父元素的收縮包圍現象。
例子： http://dev.l-c-n.com/IEW2-bugs/shrinkwrap.php
一個浮動的縱向導航無序列表并沒有收縮包圍，因為其中的鏈接為了消除列表的多余空白bug并擴展可點擊區域而擁有了 layout：a {display: block; zoom: 1;}。

這時收縮包圍現象只有在以下情況仍然有效：擁有 layout 的孩子元素同時也被賦予了一個特定寬度，或者這個孩子元素本身也是一個具有收縮包圍特性的元素，比如浮動元素。
邊緣裁切
通常而言，當一個盒子包含了諸如伸出其邊緣的內容這種更復雜的結構時，這個容器就經常需要“hasLayout”來避免一些渲染錯誤。但使用這種常用方法又會在邊界處理時左右為難，因為一個獲得“layout”的元素會變成某種自封閉的盒子。
內部的內容盒子會被裁切，比如使用負邊距向外移動時。
Clipping of negative margined blocks in a hasLayout container http://dev.l-c-n.com/IEW2-bugs/min-width-clip.php

被裁掉的部分當內容盒子觸發了“layout”時可以再次出現，但在 IE6 中需要同時擁有 position: relative 才行。IE7 在這方面要略有改觀，它不再需要額外的 position: relative 了。



堆疊，分層和 layout


IE/Win 中似乎有兩種分層和堆疊順序：
一種是(偽)試圖采用CSS的模式：Effect of z-index value to RP and AP blocks http://www.aplus.co.yu/css/z-pos/
還有一種是由“hasLayout”及其孿生兄弟“contenteditable”的行為產生的堆疊順序。正如在上面相對定位的例子中展現的那樣，在 layout 影響下的堆疊現象就好像 Harry Houdini (譯者注：魔術師，以紙牌魔術成名)的拿手戲法兒一樣。

兩種堆疊模式雖互不相容，但卻共存于IE的渲染引擎中。經驗之談：調試的時候，兩種情況都要考慮到。我們可能會有規律地在下拉菜單或者類似的復雜菜單中看到相關問題，因為它們往往牽涉到堆疊，定位和浮動等諸多令人頭疼的問題。給那些 z-index 定位的元素 layout 是一種可能的修正方法，不過也不限于此，這里只是提醒一下。
混亂的 contenteditable
如果給一個 HTML 標簽設定 contenteditable=true 屬性，比如，將會允許對該元素以及其 layout 子元素進行實時的編輯、拖動改變尺寸等操作。你可以把這屬性用在浮動元素或者一個有序列表中的 layout 列表元素上看看效果。
為了對元素進行操作(編輯它們)，“contenteditable”和“hasLayout”為那些 hasLayout 返回 true 的元素引入了一套單獨的堆疊順序。
Editing Platform http://msdn.microsoft.com/librar ... mshtmleditplatf.asp繼承了 layout 概念，對 layout 的誤解多是因 contenteditable 而起即可作為證明(那些某種程度上集成了IE編輯引擎的應用軟件多暗含著對layout概念的某種強制向后兼容性)。
More on contenteditable http://annevankesteren.nl/2005/07/more-contenteditable



和 CSS 規范類似的地方



你的 MSIE 頁面在別的瀏覽器中一團糟？我們可沒必要讓這種事情發生。如果使用恰當，任何好的瀏覽器都能擺平 MSIE 的頁面——只要你使用一些正確的 CSS。
利用 hasLayout 和“新的塊級格式化范圍”http://www.w3.org/TR/CSS21/visuren.html#q15之間的細微相似之處，我們可以有幾種方法在標準兼容瀏覽器中重新實現 hasLayout 的“包含浮動元素”http://www.w3.org/TR/CSS21/visudet.html#root-height效果，和一些“浮動元素旁邊的元素”http://www.w3.org/TR/CSS21/visuren.html#floats所特有的效果。
Reverse engineering series http://www.gunlaug.no/contents/wd_example_01.html
Simulations http://dev.l-c-n.com/IEW/simulations.php


Quirks 模式


關于這種渲染模式的的信息，請參考我們的 quirks 模式 http://www.satzansatz.de/cssd/quirksmode.html章節。
Layout ——結論
整個 layout 概念和一些基本 CSS 概念是不兼容的，即包含，排列，浮動，定位和層疊等。
由于頁面中元素或有或沒有 layout，會導致 IE/Win 的行為和 CSS 規范相違背。



擁有 layout ——另外一個引擎？



IE 的對象模型看起來是文檔模型和他們傳統的應用程序模型的糅合。我之所以提到這點是因為它對于理解IE如何渲染頁面很重要。而從文檔模型切換到應用程序模型的開關就是給一個元素“layout”。

(Dean Edwards)

有時候要解釋清楚某種行為是不可能的：就比如 hasLayout，會根據它的狀態選擇兩種不同渲染引擎的一種使用，而且每一種都有其自己的 bug 和怪異之處。



不可消除的 bug



軟件 bug 是由于在制作過程中對完整性和邏輯問題考慮不周等人為錯誤而導致的。這是人類的固有缺陷，目前還沒有什么好的解決方法。
同樣由于這種缺陷，任何試圖不重寫軟件而修復 bug 的做法，都將會不可避免的導致軟件中出現更復雜的bug。
所有依賴別的軟件的軟件——當然包括依賴操作系統，也會同樣依賴他們的 bug。于是我們會從所有關聯的軟件中得到一連串的 bug，這也更說明找到一個無 bug 軟件是幾乎不可能的。

(Molly, the cat?)

本文創建于2005年6月30日，最后一次修改于2006年4月2日。
編者：
Holly Bergevin http://positioniseverything.net/
Ingo Chao http://www.satzansatz.de/css.html
Bruno Fassino http://www.brunildo.org/
John Gallant http://positioniseverything.net/
Georg S?rtun http://www.gunlaug.no/
Philippe Wittenbergh http://emps.l-c-n.com/

特別致謝給予此項目支持的：
Dean Edwards, and Molly ?the cat?

各種語言版本：
Original(English)
Brazilian? ?Portuguese by ? ? ? ?? ? ? ?? ? ? ?? ?Mauricio Samy? ?Silva
中文版本 by old9
Italian by Gabriele Romanato

相關討論：
dean.edwards.name/weblog/

[url=mailto:spam.layout@satzansatz.de]聯系作者：[/url]

版權說明：
本文基于創作共用協議發布。



目錄



介紹
hasLayout —— 定義
術語
問題種種
Layout 從何而來
默認 layout 元素
屬性
有關內聯級別元素
腳本屬性 hasLayout
CSS hacks
Hack整理
關于 IE Mac 的小問題
MSDN文檔
分析
各種情況的詳細說明
清除浮動和自動擴展適應高度
浮動元素旁邊的元素
列表
表格
相對定位元素(r.p.)
絕對定位元素(a.p.)：包含區塊，什么是包含區塊？
濾鏡
對已渲染元素的重排(re-flow)
背景原點
邊距重疊
塊級別的鏈接
在頁面內使用鍵盤瀏覽：探索中
收縮包圍(shrink-wrapping)現象
邊緣裁切
堆疊，分層和 layout
混亂的 contenteditable
和 CSS 規范類似的地方
Quirks 模式
Layout —— 結論
擁有 layout —— 另外一個引擎？
不可消除的 bug

因為考慮到IE6、IE7瀏覽器的兼容性，所以haslayout這個屬性不得不被重視，有那么多前端開發的人和你打交道，相信你此刻也并不會寂寞了！

轉載于:https://www.cnblogs.com/huashengjam/archive/2009/09/01/1558337.html

總結

以上是生活随笔為你收集整理的寂寞的hasLayout的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。