W3C home > Mailing lists > Public > www-style@w3.org > August 2010

Re: [CSS 2.1] [Section 8.3.1] Margin collapsing and top: auto (abs. pos)

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 2 Aug 2010 16:17:27 -0700
Message-ID: <AANLkTikC3rh_ShXVvY1-Vx78GxHBouMv90vU+zkMWM9B@mail.gmail.com>
To: www-style@gtalbot.org
Cc: "www-style@w3.org" <www-style@w3.org>
2010/8/2 "GĂ©rard Talbot" <www-style@gtalbot.org>:
> Hello all,
>
> Are abs. pos. and fixed pos. elements taken out of normal flow before
> margin collapsing occurs or are abs. pos. and fixed pos. elements taken
> out of normal flow after margin collapsing occurs?

Before.

> Testcase (self-explanatory and reduced)
> --------
>
> http://www.gtalbot.org/BrowserBugsSection/css21testsuite/margin-collapsing-and-abs-pos.html
>
>
> Spec says:
> "
> The bottom margin of an in-flow block-level element is always adjoining to
> the top margin of its next in-flow block-level sibling, unless that
> sibling has clearance.
> "
> http://www.w3.org/TR/CSS21/box.html#collapsing-margins
>
> Now, "next in-flow block-level sibling" could mean not just n+1th sibling
> but n+2th sibling, n+3th sibling, n+kth sibling: this is where
> interpretation/exegesis seems critical, decisive.

Sure, it could mean the n+2th sibling, just so long as it's the next
*in-flow* sibling, like the spec states.

This doesn't seem to have anything to do with "next children", though.
 Opera collapses margins correctly in this case, same as anyone else.
(Put a height and background on #second-static and check its position
in Opera and other browsers.)

It's just computing the auto position differently, which it's allowed
to do.  (The spec only provides suggestions for how to calculate the
auto position of abspos elements, and explicitly says in 10.3.7 that
implementations are allowed to "guess at its probable position".)

~TJ
Received on Monday, 2 August 2010 23:18:20 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:30 GMT