- From: Alex Mogilevsky <alexmog@microsoft.com>
- Date: Tue, 24 Feb 2009 15:52:40 -0800
- To: "www-style@w3.org" <www-style@w3.org>, Ian Hickson <ian@hixie.ch>
- Message-ID: <7C2F64B551D8664AAD94A28DAC37D0206B5E9171B9@NA-EXMSG-C103.redmond.corp.microsoft>
In this test http://hixie.ch/tests/adhoc/css/box/absolute/020.html expected "auto" position of the green block doesn't include full results effect of margin collapsing. To pass the test, UA would have to calculated 'static' position as if the element "b" *really* wasn't positioned, including effect of that on margin collapsing (non-positioned "b" would prevent collapsing of top margin of "c4" with body, thus producing expected top of 10px). The expected behavior is possible, and certainly allowed by CSS2.1 (which has very flexible language for static position in 10.3.7 and 10.6.4 [1]). It seems however that most browsers (Firefox, Safari and IE8) choose to not change margin collapsing for the purposes of calculating static position (resulting in element "b" being aligned with <body> element, and red showing in this test). Although either behavior is correct in CSS2.1, which behavior would we consider preferable? In my opinion, margin collapsing should have full effect when calculating static position, even though placing the same element in "normal flow" would disrupt margin collapsing. Following this logic also makes vertical position of absolute position elements with 'top:auto' consistent with vertical position of floats in same context. [1] http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-width -- "But rather than actually calculating the dimensions of that hypothetical box, user agents are free to make a guess at its probable position." Thanks Alex
Received on Tuesday, 24 February 2009 23:53:31 UTC