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)
http://lists.w3.org/Archives/Public/www-style/2010Aug/0014.html

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
'auto'.
"
http://www.w3.org/TR/CSS21/tables.html#fixed-table-layout


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

Gérard
-- 
Contributions to the CSS 2.1 test suite:
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/

CSS 2.1 Test suite RC6, March 23rd 2011:
http://test.csswg.org/suites/css2.1/20110323/html4/toc.html

CSS 2.1 test suite harness:
http://test.csswg.org/harness/

Contributing to to CSS 2.1 test suite:
http://www.gtalbot.org/BrowserBugsSection/css21testsuite/web-authors-contributions-css21-testsuite.html
Received on Monday, 10 September 2012 19:42:28 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 10 September 2012 19:42:34 GMT