W3C home > Mailing lists > Public > public-css-testsuite@w3.org > September 2012

Re: [RC6] abspos-010 test: 5 new margin-collapse-012 tests

From: Gérard Talbot <css21testsuite@gtalbot.org>
Date: Mon, 10 Sep 2012 15:42:01 -0400
Message-ID: <c736194198a0c26f61407850ce2264d5.squirrel@ed-sh-cp3.entirelydigital.com>
To: "Øyvind Stenhaug" <oyvinds@opera.com>
Cc: "Public CSS test suite mailing list" <public-css-testsuite@w3.org>

Le Lun 10 septembre 2012 5:34, Øyvind Stenhaug a écrit :
> On Mon, 10 Sep 2012 03:20:24 +0200, Gérard Talbot
> <css21testsuite@gtalbot.org> wrote:
>> [RC6]
>> http://test.csswg.org/suites/css2.1/20110323/html4/abspos-010.htm
>> [nightly-unstable]
>> http://test.csswg.org/suites/css2.1/nightly-unstable/html4/abspos-010.htm
>> If you examine this test with various browsers, you'll notice a
>> difference of rendering (height of green area):
>> Opera 12.02, Chrome 21.0.1180.89, Safari 5.1.7, Konqueror 4.9.0 all
>> render a 48px wide by 48px tall green square.
>> Firefox 15.0 and IE8 render a 48px wide by 64px tall green rectangle.
>> The difference is due to how vertical margins are supposed to be
>> rendered: the 2em margin-top of the abs. pos. table (.fixed) should
>> *not* collapse with margin-bottom of <p>. So, Firefox 15.0 and IE8 are
>> correct.
> I disagree with this part. The ".fixed" table is absolutely positioned
> and
> has top:auto, so
> http://www.w3.org/TR/CSS21/visudet.html#abs-non-replaced-height says the
> vertical position should be determined as if position had been static
> (and
> float:none; clear:none). In that case the margins *would* collapse.
> Of course, the part "user agents are free to make a guess at its
> probable
> position" means Firefox and IE can't be said to be violating the spec
> either...

I am re-reading this thread
[CSS 2.1] [Section 8.3.1] Margin collapsing and top: auto (abs. pos)

There are more differences if involved elements with collapsible margins
are empty.

We may have to add the "may" flag to all those (margin-collapse-012) tests.

>> So, I revisited
>> [RC6]
>> http://test.csswg.org/suites/css2.1/20110323/html4/margin-collapse-012.htm
>> [nightly-unstable]
>> http://test.csswg.org/suites/css2.1/nightly-unstable/html4/margin-collapse-012.htm
>> and noticed that a few more tests could be submitted to better cover
>> possibilities:
>> With margin-bottom:
>> http://test.csswg.org/source/contributors/gtalbot/submitted/margin-collapse-012a.xht
>> With a collapsed-through element:
>> http://test.csswg.org/source/contributors/gtalbot/submitted/margin-collapse-012b.xht
>> With with margin-top (with an abs. pos. table):
>> http://test.csswg.org/source/contributors/gtalbot/submitted/margin-collapse-012c.xht
>> With margin-bottom (with an abs. pos. table):
>> http://test.csswg.org/source/contributors/gtalbot/submitted/margin-collapse-012d.xht
>> With a collapsed-through element (with an abs. pos. table):
>> http://test.csswg.org/source/contributors/gtalbot/submitted/margin-collapse-012e.xht
> I haven't examined all these in detail, but I think they are wrong
> because
> of the above.
>> abspos-010 test seems wrong too because table-layout: fixed does not
>> apply if (at minimum) width of table is not specified... and the test
>> uses a table that has 1 single row which has 1 single cell..
> Well, not really wrong, although the .fixed part seems to test the fixed
> table layout section

'table-layout: fixed' is declared for the 2nd table but the test is not
triggering the fixed table layout algorithm for such 2nd table.

The table's width may be specified explicitly with the 'width' property.
A value of 'auto' (for both 'display: table' and 'display:
inline-table') means use the automatic table layout algorithm. However,
if the table is a block-level table ('display: table') in normal flow, a
UA may (but does not have to) use the algorithm of 10.3.3 to compute a
width and apply fixed table layout even if the specified width is

> more than it does the abs. pos. one.
>> Right now, I think this test is not good, not trustworthy because it
>> does not achieve the original goal/intent of the test. Such test, as
>> designed, does not demonstrate the goal of the test.
> It should probably just refrain from relying on auto abs.pos. position,
> since that doesn't seem relevant. (The tables could be wrapped in a
> relatively-positioned div, "top:0; left: 0" be set in the "table"
> declaration block and "margin-" be deleted from the ".fixed" block or
> something like that.)

That's a work around to avoid the 'top: auto' and margin collapsing
issue. I think we first need to create a real test where a table with
'table-layout: fixed' and a table with 'table-layout: auto' are creating
a difference of width and then verify that such difference disappears if
abs. positioning is applied. And, in my opinion, creating a test
involving a table requires a minimum of 2 rows and 2 cells per row, and
preferably with some content. It's not just for a realistic web
scenario, it's also because tests with one row and 1 empty cell have in
the past given false positives.

> Though with the apparent goal of the test being to check that
> "Absolutely
> positioned tables must shrink wrap", it is unfortunate that "CSS 2.1
> does
> not define the exact algorithm" for shrink-to-fit...

Yes. That's another difficulty with the spec.

Contributions to the CSS 2.1 test suite:

CSS 2.1 Test suite RC6, March 23rd 2011:

CSS 2.1 test suite harness:

Contributing to to CSS 2.1 test suite:
Received on Monday, 10 September 2012 19:42:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:25 UTC