|
分析
我們的分析試圖解釋在已知案例下發(fā)生了什么事情，這種分析也應該可以作為未知案例下的指導。但我們這種試圖利用種種測試案例投石探路的黑箱測試方法，是注定無法消除黑箱的神秘感的——我們無法回答“為什么”的問題。我們只能去嘗試了解整個“hasLayout”模式的工作框架，以及它會怎樣影響網(wǎng)頁文檔的渲染。因此，最終我們只能提供一些指導方針(而且只能是指導方針，而不是絕對的解決方案)。
我們認為他們所指的是一個小窗體。一個 layout 元素的內(nèi)部內(nèi)容是完全獨立的，而且也無法影響其邊界外的任何內(nèi)容。
而 MS 屬性 layout 只是某種標志位：一旦它被設定，這個元素就會擁有 layout“特性”，這包括體現(xiàn)在其自身以及其非 layout 孩子元素身上的特殊性能——比如浮動和層疊等。
這種獨立性也許正可以解釋為什么 layout 元素通常比較穩(wěn)定，而且它們可以讓某些 bug 消失。這種情況的代價有二，一是偏離了標準，二是它沒有考慮到今后可能因此出現(xiàn)的 bug 和問題。
MS 的“頁面”模式，從符號學角度考慮，可以看做是由很多互不相關的小的區(qū)塊構成，而 HTML 和 W3C 的模式則認為“頁面”模式應該是敘述完備的，故事性的相關信息區(qū)塊構成的。
各種情況的詳細說明
清除浮動和自動擴展適應高度
浮動元素會被 layou 元素自動包含。這是很多新手經(jīng)常遇到的問題：在 IE 下完成的頁面到了標準兼容瀏覽器下所有未清除的浮動元素都伸出了其包含容器之外
·Containing Floats
·how to clear floats without structural markup
相反的情況：如果確實需要一個浮動元素伸出其包含容器，也就是自動包含不是想要的效果時，該怎么辦？你很可能也會遇到這種頭疼的問題，下面的深入討論就是一個例子：
·acidic float tests
在IE中，一個浮動元素總是“隸屬于”它的 layout 包含容器。而后面的元素會受這個 layout 包含容器影響而不是這個浮動元素影響。
這個特性和IE6的那個自動擴展以適應內(nèi)部內(nèi)容寬度的特性，都可以看成是受這個規(guī)則影響的：“由它的邊界矩形框決定”。
更糟的問題：clear 無法影響其 layout 包含容器之外的 float 元素。如果依賴這個 bug 在 IE 中布局的頁面要轉到標準兼容瀏覽器中，只有全部重做。
IE 的自動包含浮動元素也是經(jīng)常需要的效果，它在其他瀏覽器中也可以達到：參考我們的 “和 CSS 規(guī)范類似的地方” 這一部分來了解一下包含浮動元素的相關內(nèi)容。
浮動元素旁邊的元素
當一個塊級元素緊跟在一個左浮動元素之后時，它應該——作為一個塊級元素——忽略這個浮動元素，而它的內(nèi)容則應該因這個浮動元素而移位：一個緊跟在左浮動元素后的塊級元素內(nèi)的文字內(nèi)容，應該沿著浮動元素的右邊順序排列并會（如果它的長度超過浮動元素）繼續(xù)排列到浮動元素下方。但是如果這個塊級元素有 layout，比如由于某種原因被設置了寬度，那么這整個元素則會因浮動元素而移位，就好像它自己也是一個浮動元素一樣，因此其中的文字就不再環(huán)繞這個左浮動元素了（而會形成一個矩形區(qū)域，保持在它的右邊。）
在 IE5 中一個塊級元素的百分比寬度是基于浮動元素旁邊的剩余空間計算的，而在 IE6 中則是依照整個父塊級元素的可用空間計算的。所以在 IE6 中設置 width: 100% 會導致某種浮動元素旁邊的溢出現(xiàn)象，于是各種布局問題也會因此而來。
一些關于浮動塊旁邊的 hasLayout 塊的測試案例：
·by using width
·by using min-width (IE 7) and zoom (IE 6)
與此類似，和浮動元素相鄰的相對定位元素，它的位置偏移量應該參照的是父元素的補白(padding)邊緣(例如，left: 0; 應該將一個相對定位元素疊放于它前面的浮動元素之上)。在 IE6 中，偏移量 left: value; 是從浮動元素的右邊距(margin)邊緣開始算起的，這會因浮動元素所占的寬度變化導致水平方向的錯位(一個解決方法是用 margin-left 代替，但是也要注意如使用百分值時會有一些怪異問題)。
·layout blocks with relative positioning adjacent to floated blocks
根據(jù)規(guī)范所述，浮動元素應該與其后的盒子交織在一起。而對于沒有交叉的二維空間中的矩形而言這是無法實現(xiàn)的。
如果誰真的需要向 IE 的這種不當行為屈服，那么如何讓標準兼容瀏覽器中的盒子也有類似行為——即類似于 layout 盒子會自動“收縮”而給其前置的浮動元素讓出空間的行為——就是一個問題了。我們給出的方法是跟著一個浮動元素創(chuàng)建一個新的塊級格式化范圍（block formatting context），這在我們的“和 CSS 規(guī)范類似的地方” 有討論。
可以(再次)訪問下面這個頁面：
·three pixel text-jog
我們可以看到跟在一個浮動元素后的 layout 元素不會顯示這個3px間隙的 bug，因為浮動元素外圍的3px硬邊無法影響一個 layout 元素的內(nèi)部內(nèi)容，所以這個硬邊將整個 layout 元素右推了3px。好比一個防護罩，layout 可以保護其內(nèi)部內(nèi)容不受影響，但是浮動元素的力量卻將整個防護罩推了開來。
列表
無論是列表本身(ol, ul) 還是單個的列表元素(li)，擁有 layout 后都會影響列表的表現(xiàn)。不同版本 IE 的表現(xiàn)又有不同。最明顯的效果就體現(xiàn)在列表符號上(如果你的列表自定義了列表符號則不會受這個問題影響)。這些符號很可能是通過某種內(nèi)部機制附到列表元素上的(通常是附著在它們外面)。不幸的是，由于是通過“內(nèi)部機制”添加的，我們無法訪問它們也無法修正它們的錯誤表現(xiàn)。
最明顯的效果有：
·列表獲得 layout 后，列表符號會消失或者被放置在不同的或者錯誤的位置。
有時它們又可以通過改變列表元素的邊距而重新出現(xiàn)。這看起來似乎是以下事實導致的結果：layout 元素會試圖裁掉超出其邊界的內(nèi)部內(nèi)容。
·列表元素獲得 layout 之后，會有和上面一樣的問題出現(xiàn)，更多參考 (extra vertical space between list items)http://www.brunildo.org/test/IEWlispace.php
進一步又有一個問題就是(在有序列表中)任何具有 layout 的列表元素似乎都有自己獨立的計數(shù)器。比如我們有一個含五個列表元素的有序列表，只有第三個列表元素有 layout。我們會看到這樣：
1… 2… 1… 4… 5…
·此外，如果一個有 layout 的列表元素跨行顯示時，列表符號會底部對齊(而不是按照預料的頂部對齊)。
·以上某些問題還是無法解決的，所以如果需要列表符號的時候最好避免讓列表和列表元素獲得 layout。如果需要限定尺寸，最好給別的元素設定尺寸，比如給整個列表外面套一個元素并設定它的寬度，又或者比如給每個列表元素中的內(nèi)容設定高度等等。
·另一個IE中列表的常見問題出現(xiàn)在當某個 li 中的內(nèi)容是一個 display: block 的錨點(anchor)時。在這種情況下，列表元素之間的空格將不會被忽略而且通常會顯示成額外的一行夾在每個 li 之間。一種避免這種豎直方向多余空白的解決方法是賦予這些錨點 layout。這樣還有一個好處就是可以讓整個錨點的矩形區(qū)域都可以響應鼠標點擊。
出處：web.Frontend
責任編輯：moby
上一頁 On having layout [2] 下一頁 On having layout [4]
◎進入論壇網(wǎng)站綜合、網(wǎng)頁制作版塊參加討論
|
第 1 頁 
第 3 頁 On having layout [3]
