W3C關於BFC的一個解釋:css
看起來比較蛋疼是吧,另外一個通俗點的解釋是:在普通流中的 Box(框) 屬於一種 formatting context(格式化上下文) ,類型能夠是 block ,或者是 inline ,但不能同時屬於這二者。而且, Block boxes(塊框) 在 block formatting context(塊格式化上下文) 裏格式化, Inline boxes(塊內框) 則在 inline formatting context(行內格式化上下文) 裏格式化。任何被渲染的元素都屬於一個 box ,而且不是 block ,就是 inline 。即便是未被任何元素包裹的文本,根據不一樣的狀況,也會屬於匿名的 block boxes 或者 inline boxes。因此上面的描述,便是把全部的元素劃分到對應的 formatting context 裏。瀏覽器
那BFC究竟是啥?就是一個做用範圍。能夠把它理解成是一個獨立的容器,而且這個容器的裏box的佈局,與這個容器外的絕不相干。佈局
簡單地說:Block Formatting Context就是頁面上的一個隔離的獨立容器,容器裏面的子元素不會在佈局上影響到外面的元素,反之也是如此。orm
看看BFC的觸發條件get
而BFC的特性是it
第一個margin不會疊加的特性,能夠理解爲兩個處於普通流的盒子,會有margin疊加的問題,是由於他們屬於相同的BFC,當他自身建立了一個新的BFC時,這個問題就不存在了io
第二個特性就特別有用了,由於元素觸發了BFC的話,就不會被float元素覆蓋,當子元素所有浮動的時候也可以正確地包含了table
可是在 IE6 IE7 IE8(Q) 中沒有觸發 hasLayout 並在其餘瀏覽器中建立了 Block Formatting Context 的元素的表現會有差別。具體能夠參考w3helpform
保險的解決方案就是既觸發IE的hasLayout,又觸發BFC,具體的css就是既overflow:hidden,又zoom:1(雖然zoom並不能經過校驗),另外overflow還有一個問題就是會影響盒子的表現class
相對於常常要限寬,還有一大堆BUG的float來佈局,用BFC來佈局會至關方便