Note that in this paper, discussion of the CSS 2.1 Candidate Recommendation is made in reference to the latest revision (2007-07-19) at the time of initial publication.
Internet Explorer 6 does not conform to the positioning model specified by CSS 2.1 CR. In its non-standard positioning model, the position of an absolutely positioned element with a block-level nearest positioned ancestor depends on many factors including whether that ancestor is hasLayout, whether that ancestor has non-zero padding-top or border-top, whether that ancestor has floated descendants and whether that ancestor has inline-level or block-level in-flow content. This paper provides a detailed description of parts of the positioning model in Internet Explorer 6. It also describes those aspects of the inline formatting model in Internet Explorer 6 that are necessary to formulate the positioning model. Many minimal test cases are then presented.
Warning: Hypotheses and conclusions formed in this paper are purely the result of analysing test cases, and are of course subject to change as new test cases appear. Accordingly, this paper is a “work in progress”. Indeed, there exist factors which are known to influence the positioning model but which are excluded from the discussion by placing restrictions on the conditions of the document and its associated styles.
CSS 2.1 Candidate Recommendation (CSS 2.1 CR) states the following.
[9.6 Absolute positioning] In the absolute positioning model, a box is explicitly offset with respect to its containing block.
[10.1 Definition of “containing block”] If an element has ‘position: absolute’, the containing block is established by the nearest ancestor with a ‘position’ of ‘absolute’, ‘relative’ or ‘fixed’, in the following way:
- In the case that the ancestor is inline-level, the containing block depends on the ‘direction’ property of the ancestor:
Note: This may cause the containing block’s width to be negative.
- If the ‘direction’ is ‘ltr’, the top and left of the containing block are the top and left padding edges of the first box generated by the ancestor, and the bottom and right are the bottom and right padding edges of the last box of the ancestor.
- If the ‘direction’ is ‘rtl’, the top and right are the top and right padding edges of the first box generated by the ancestor, and the bottom and left are the bottom and left padding edges of the last box of the ancestor.
- Otherwise, the containing block is formed by the padding edge of the ancestor.
If there is no such ancestor, the containing block is the initial containing block.
Sections 10.3.7 and 10.6.4 (Absolutely positioned, non-replaced elements) provide technical details on the position of an AP box when some or all of the positioning properties ‘top’, ‘right’, ‘bottom’, ‘left’ have the value ‘auto’.
We make the following definitions (not used in CSS 2.1 CR).
The position of an absolutely positioned (AP) element is the location of the top left corner of its margin area. Its home positioning origin is its position when its calculated style is “left: 0; right: auto; top: 0; bottom: auto; width: auto; height: auto”. (So when an AP element’s nearest positioned ancestor is block-level, CSS 2.1 CR says that its home positioning origin is the top left corner of the ancestor’s padding area.)
The positioning context P of an element E is the nearest positioned ancestor of E, or the root element if E has no such ancestor. E is said to be position-dependent on P.
An element E is said to be layout-dependent on its nearest ancestor element which is either positioned or establishes a new block formatting context.
The maximal sequence S of a float F is the maximal source-consecutive sequence of sibling floated and AP elements to which F belongs. Let P be the positioning context of F. The maximal sequence S of F is said to be opening if there is no layout-dependent descendant of P which precedes S.
A line box L is said to be influenced by the maximal sequence S of a float F if it is layout-dependent on the positioning context P of F and if its position would, in a CSS 2.1 CR–compliant browser, lie on a horizontal line through the margin area of some float in S.
Recall from CSS 2.1 CR that anonymous inline boxes and inline boxes of inline non-replaced elements are to be treated as having no vertical padding, borders or margin when flowing them into line boxes, vertically aligning them, and calculating the line boxes’ line-height. Any vertical padding, borders and margin has overflow-like behaviour in that it may overlap other boxes without influencing their position or dimensions. Line boxes themselves are stacked with no vertical separation and they never overlap.
IE6 can be thought of as possessing a non-standard line box model in addition to the CSS 2.1 CR line box model: to each line box as described above there corresponds a virtual outer line box obtained by ‘stretching’ the line box upwards and/or downwards the minimum distance necessary to contain the border area of its inline boxes’ borders. Similarly, IE6 can be thought of as possessing a non-standard box model in addition to the CSS 2.1 CR box model that it possesses in standards-compliant mode: the virtual outer content area of a block-level element’s box is obtained by ‘stretching’ its standard content area upwards and/or downwards the minimum distance necessary to contain its virtual outer line boxes. The virtual outer padding, border and margin areas are obtained by adding padding, border and margin to the virtual outer content area, analogously to the CSS 2.1 CR box model. IE6’s non-standard line box model and box model are in many respects benign; however, they influence the calculation of static position and home positioning origin.
IE6 deviates from the inline formatting model specified in CSS 2.1 CR in the following ways.
Internet Explorer 6 does not conform to the positioning model specified by CSS 2.1 CR. In its non-standard positioning model, the position of a given AP element with a block-level nearest positioned ancestor depends on many factors including whether that ancestor is hasLayout, whether that ancestor has non-zero padding-top or border-top, whether that ancestor has floated descendants and whether that ancestor has inline-level or block-level in-flow content.
Quick tests indicate that wrapped inline hasLayout clears complicate the situation further.
(Note that in this example we see the “block-level child’s vertical margin collapses with hasLayout parent’s padding” bug affecting the in-flow block-level box.)
(Note that in this example we see that the hasLayout parent expands to contain its floated content.)