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: Gérard Talbot <www-style@gtalbot.org>
Date: Mon, 2 Aug 2010 18:40:38 -0700
Message-ID: <e70ed77dc73abe3de2426a8d819e1258.squirrel@cp3.shieldhost.com>
To: "www-style@w3.org" <www-style@w3.org>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>

Le Lun 2 août 2010 16:17, Tab Atkins Jr. a écrit :
> 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.

Hmm... I think I may not have correctly created a reduced testcase from
Ian Hickson's testcase after all...

>  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.)

I have done this right here:

http://www.gtalbot.org/BrowserBugsSection/css21testsuite/margin-collapsing-and-abs-pos-Tab-Atkins.html

My initial testcase (and Ian Hickson's testcases) involved empty divs with
margins.

> 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

Well, then, in such case,

http://test.csswg.org/suites/css2.1/20100727/html4/abspos-021.htm

should be rejected because the rendered layout can be rendered differently.


I need to take a pause and re-examine all this carefully. My testcase may
not be a correct reduction of Ian Hickson testcase to start with.

regards, Gérard
-- 
CSS 2.1 Test suite beta 2 (July 27th 2010)
http://test.csswg.org/suites/css2.1/20100727/html4/toc.html

Contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/

Web authors' contributions to CSS 2.1 test suite
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html
Received on Tuesday, 3 August 2010 01:41:15 GMT

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