On Feb 24, 2010, at 7:15 PM, Bruno Fassino wrote: > Philippe Wittenbergh wrote: > > >> Alan's testcase (#2) is different in that what moves things around is a top >> margin of an element that follows the a.p.-element. I think you're right to >> say (quoted below) that there is more ambiguity in the spec. Opera seems to >> compute top before taking the margin collapsing into account, others do it >> having already taken that margin-collapsing into consideration. > > > Ah, yes, I see. > > There are probably other cases with different "interpretations". For > example I see here > http://www.brunildo.org/test/Op_top_auto.html > that Gecko and Webkit differ. The a.p. box has a margin-top. When > calculating the top:auto position Webkit makes the a.p. margin-top to > collapse with a previous margin-bottom, Gecko does not. > Again, I don't think we can "strictly" say that one is correct, and > the other not.
Hmm. funky. We have 8.3.1 Collapsing margins that says: Margins of absolutely positioned boxes do not collapse (not even with their in-flow children) WebKit is apparently ignoring this. Or partly ignoring this. I'm not sure if this is how Gecko processes the information/requirements from the stylesheet: 1. place the element as if it were static --> top margin collapses 2. element becomes absolute positioned --> taken out of the flow. (2nd pass) 3. we need to recompute the top-margin now to take into account the constrains of 8.3.1 </slightly confused> or is it the spec ? Philippe --- Philippe Wittenbergh http://l-c-n.com/ ______________________________________________________________________ css-discuss [[email protected]] http://www.css-discuss.org/mailman/listinfo/css-d List wiki/FAQ -- http://css-discuss.incutio.com/ List policies -- http://css-discuss.org/policies.html Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
