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: Tue, 3 Aug 2010 19:14:54 -0700
Message-ID: <b1b8feab9ef211945acd818a880826a2.squirrel@cp3.shieldhost.com>
To: "www-style@w3.org" <www-style@w3.org>
Cc: "Alan Gresley" <alan@css-class.com>, "Tab Atkins Jr." <jackalmage@gmail.com>

Le Mar 3 août 2010 11:16, Tab Atkins Jr. a écrit :
> 2010/8/2 "Gérard Talbot" <www-style@gtalbot.org>:
>> Le Lun 2 aoūt 2010 16:17, Tab Atkins Jr. a écrit :
>>> 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.
> Right, the behavior is different if the first element is empty or not.
>  I think everyone agrees about the rendering for that case?
> The differing behavior occurs when the first element is empty, and
> thus the margin-top of #second-static collapses all the way up into
> the top margin of #first-static.
>>> 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".)

Tab, the same is repeated in section 10.6.4. So the same (leniency,
flexibility) applies to left: auto and top: auto.

Section 10.3.7 Absolutely positioned, non-replaced elements
(...)  The static position for 'left' is the distance from the left edge
of the containing block to the left margin edge of a hypothetical box that
would have been the first box of the element if its 'position' property
had been 'static' and 'float' had been 'none'. (...)
But rather than actually calculating the dimensions of that hypothetical
box, user agents are free to make a guess at its probable position.

Section 10.6.4 Absolutely positioned, non-replaced elements
(...) the static position for 'top' is the distance from the top edge of
the containing block to the top margin edge of a hypothetical box that
would have been the first box of the element if its specified 'position'
value had been 'static' and its specified 'float' had been 'none' and
'clear' had been 'none'.
(...) But rather than actually calculating the dimensions of that
hypothetical box, user agents are free to make a guess at its probable

>>> ~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 suspect that *any* testcases based on auto positioning of abspos
> elements should be rejected, due to the explicit allowance of
> different renderings.

Well, then I have a list of auto positioning of abspos elements testcases
here which may be rejectable :

CSS Test: position: fixed; top: auto; test - margin collapsing

CSS Test: left:auto for fixed-pos blocks inside abs-pos blocks
(it does rely on top: auto as well)

Absolutely positioned, non-replaced elements, static position of fixed
"The calculation of static position is based on initial containing block
when there is a fixed positioned element."

and there may be others as well.

>From my own tests:

> It sucks, and we *should* tighten that up, but right now it's not
> something testable

Then those tests should be removed.

>, and implementations disagree in several
> situations.

Well, so far, in my own testing, only Opera sometimes and Chrome/webkit
sometimes disagree in some tests. Maybe there's more disagreements in
other tests...

> (For example, try absposing a table-cell with auto
> positions.)

Tab, absposing a table-cell with auto positions should be a punishable
crime or something like that :)

"Note. Positioning and floating of table cells can cause them not to be
table cells anymore, according to the rules in section 9.7."

"Note. Table cells may be relatively and absolutely positioned, but this
is not recommended: positioning and floating remove a box from the flow,
affecting table alignment."

And relposing a table-cell or any sub-table elements is formally
discouraged too:

The effect of 'position:relative' on table-row-group, table-header-group,
table-footer-group, table-row, table-column-group, table-column,
table-cell, and table-caption elements is undefined.

Anyway... I need to take a pause and look at all this (Alan's testcases)
again, carefully.

regards, Gérard
CSS 2.1 Test suite beta 2 (July 27th 2010)

Contributions to CSS 2.1 test suite

Web authors' contributions to CSS 2.1 test suite
Received on Wednesday, 4 August 2010 02:15:31 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:37 UTC