But according to the CSS level 3 specification, a block formatting context (a “flow root” in CSS3 speak) is created when the following condition is met:
The value of "position" is neither "static" nor "relative" (see [CSS3POS]).http://www.w3.org/TR/css3-box/#block-level0
This definition means that
position:fixed establishes a new block formatting context, too. This is not a miss in section 9.4.1, though; fixed positioning is a subcategory of absolute positioning (9.6.1) andreferences in the specification to an absolutely positioned element (or its box) imply that the element’s “position” property has the value “absolute” or “fixed”.
display:table does not establish block formatting contexts per se. But because it can generate anonymous boxes, one of them (with
display:table-cell) establishes a new block formatting context. In other words, the trigger is the anonymous box, not
display:table. This is something authors should keep in mind, because even if both styles establish new block-formatting contexts (implicitly or explicitly),
clear does not work the same with
display:table as it does with
A final trigger is the
fieldset element. Oddly enough, there was no information on www.w3.org about this behavior until the HTML5 specification. There were browser bugs (Webkit, Mozilla) that mentioned this, but nothing “official”. Actually, even if fieldsets establish new block formatting contexts in most browsers, as per section 3.2 (UA conformance), authors were not supposed to take this for granted:
CSS 2.1 does not define which properties apply to form controls and frames, or how CSS can be used to style them. User agents may apply CSS properties to these elements. Authors are recommended to treat such support as experimental. A future level of CSS may specify this further.http://www.w3.org/TR/CSS21/conform.html
Block formatting contexts contain floats because of the way they flow, and per section 9.4.1, they prevent collapsing margins and do not overlap floats:
- In a block formatting context, boxes are laid out one after the other, vertically, beginning at the top of a containing block. The vertical distance between two sibling boxes is determined by the “margin” properties. Vertical margins between adjacent block boxes in a block formatting context collapse
- In a block formatting context, each box’s left outer edge touches the left edge of the containing block (for right-to-left formatting, right edges touch). This is true even in the presence of floats (although a box’s line boxes may shrink due to the floats), unless the box establishes a new block formatting context (in which case the box itself may become narrower due to the floats)
Block formatting contexts behave more or less like any block box, apart from these important exceptions:
Vertical margins between adjacent block boxes collapse, but only if they are in the same block formatting context. In other words, if the adjacent boxes do not belong to the same block formatting context, their margin will not collapse.
This is a paragraph inside a DIV with a bluish background, styled with
This is a paragraph inside a DIV with a bluish background, styled with
Between the two first bluish boxes above, the bottom and top margin of the paragraphs collapse (the gap equals 20 pixels, not 40 pixels), but because the last DIV creates a new block-formatting context, the margins of the third paragraph do not collapse, hence they do not “stick out” of the paragraph’s container but instead are part of that block box.
(Note: in IE6, without explicit margins the DIV would fail to enclose the margins.)
When it comes to collapsing margins, creating a new block-formatting context acts the same as applying
padding to the element.
I am sure you have heard of the sentence “a float always contains floats”, or maybe heard of the FNE (
float nearly everything) method. But the basis of this is that floats are block formatting contexts, so a better way to formulate this is to say that “a block formatting context always contains floats”.
This paragraph is a float inside a DIV with a bluish background, it is styled with
The first paragraph above is a float so it is removed from the flow and its container collapses, hence the background of this container does not show.
The second paragraph is also a float, but it is contained inside a DIV that creates a new block formatting context, hence that container encloses the child’s “margin box”. You should also note that, unlike with the first paragraph, there is no need to clear the previous box. This is often referred to as “self-clearing”, which makes lot of sense considering that block formatting contexts are a normal part of the flow.
clear only clears floats within the same block formatting context.)
This one is my favorite. According to the spec, the border-box of a block formatting context must not overlap the margin-box of floats in the same block formatting context as the element itself. What this means is that browsers create implicit margins on block formatting contexts to prevent them from overlapping the margin-box of floats.
float: left; width: 160px;
float: right; width: 160px;
Because this behavior is attached to the border box (not the margin box), to create space (e.g., a 20px gap) between the pink box and its siblings, authors would need to either:
Yes, you’d use
20px. Because it is the border-box that tries to fit between the floats, not the margin-box. And if I say it tries it is because that container would drop if there was not enough room for it between the two floats.
In other words, if the pink box was given a 400 pixels width, that box should drop when the parent container is narrower than 730 pixels (160px + 160px + 400px + 10px).
Note: the space that shows in IE6 between the pink box and the two floats is due to the three pixel jog bug.
As you may have noticed, all previous examples are styled using
overflow:hidden;zoom:1. The former declaration establishes a new block formatting context in modern browsers while the latter triggers hasLayout in Internet Explorer (IE 5.5/6/7). This is because these renderings are very close (similarities with the CSS specs). Like block formatting contexts, elements that are given a layout appear to prevent collapsing margins, to contain floats, and to not overlap floats.
The lists below show that the properties that establish a new block formatting context also trigger hasLayout, at least the ones supported by the browser, with the exception of
overflow in IE < 7.
float(any value other than
width(any value other than
height(any value other than
zoom(any value other than
max-width(any value other than
max-height(any value other than
overflow(any value other than
overflow-y(any value other than
writing-modeare proprietary properties and do not validate.
heighttrigger hasLayout on inline elements only when these properties apply to these elements (i.e., IE6 in quirks mode).
overflow-yare part of the CSS3 box model module
In Quirks Mode and IE7 Mode (All Versions)
In Internet Explorer, these elements have – by default – a layout:
<body>(as well as
<html>in Strict mode)
To reduce the risk of issues between modern browsers and Internet Explorer (< 8), authors may choose to give a layout to boxes that establish new block formatting contexts. This way the flow is identical, elements escape floats the same way,
clear clears the same floats, and margins collapse where expected. Also, authors must pay attention when styling boxes using hasLayout triggers (i.e.,
width) as such styling may require making that element a new block formatting context as well.
Special thanks to Philippe Wittenbergh and Bruno Fassino for finding spec references when one needs them and to Ingo Chao for giving us the best resource on having layout.