W3C home > Mailing lists > Public > public-css-testsuite@w3.org > November 2010

[RC3] containing-block-017 and containing-block-003 not testing what they are supposed to test

From: Gérard Talbot <css21testsuite@gtalbot.org>
Date: Fri, 19 Nov 2010 12:13:08 -0800
Message-ID: <776dd458e62b034ecadba9ce5928d3d4.squirrel@cp3.shieldhost.com>
To: "Arron Eicholz" <Arron.Eicholz@microsoft.com>
Cc: "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>
Hello,


http://test.csswg.org/suites/css2.1/20101027/html4/containing-block-017.htm

http://test.csswg.org/suites/css2.1/20101027/xhtml1/containing-block-017.xht

http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_10/containing-block-017.xht

1-
        <meta name="assert" content="The containing block is formed by
the padding edge for block-level elements." />

I think the meta assert should be more precise and say:

        <meta name="assert" content="The containing block of an
absolutely positioned block-level element is formed by the
padding edge of its nearest (closest) positioned ancestor
element." />

2- As coded, the testcase positions the innermost span (styled as block)
at 'top: auto' and 'left: auto' (and not some specified value which
would then be related to padding box of nearest positioned ancestor)
which is the top & left position it would have had if it had been
positioned statically. Now, that position is given by its outer-parent
span (#span1) which also coincide with the upper-left corner content box
of the wrapping rel-pos <div>. So, while the testcase says/refers to the
padding box, the testcase actually positions the innermost span in the
content box of its nearest (closest) positioned ancestor element. It's
awkward and at first sight contradicts the purpose of the testcase

3- Overall, that testcase could be redesigned entirely to better (more
clearly, more cleanly) target the goal given in the assert text.


------------------


http://test.csswg.org/suites/css2.1/20101027/html4/containing-block-003.htm

http://test.csswg.org/suites/css2.1/20101027/xhtml1/containing-block-003.xht

http://test.csswg.org/source/contributors/microsoft/submitted/Chapter_10/containing-block-003.xht

            #div1
            {
                background: red;
                display: inline-block;
                height: 100px;
                width: 100px;
            }
            div div
            {
                background: green;
                height: 100%;
                position: relative;
                width: 100%;
            }

(...)

  <p>Test passes if there is no red visible on the page.</p>
        <div id="div1">
            <div></div>
        </div>


1- If position is static (instead of relative), the testcase passes
anyway. Ideally, you would want the test to fail if position was static.
2- If width is auto (instead of 100%), the testcase passes anyway.
Width: 100% is not necessary, not needed in that testcase.
3- top is auto and left is auto and so not using specified values with
which the testcase could verify position with, say, the overlapping
technique.
4- #div1 has no padding area and no border area; so all 3 areas (border,
padding, content) are/occupy the same area. If the testcase's goal is
about content edge of the nearest inline-block ancestor box, then such
inline-block ancestor box should have a padding box (ideally with a
distinctive background color).
5- Even IE6 passes that testcase!

Overall, the testcase is just way too easy to pass and will not test
clearly and cleanly how relatively positioned layers are positioned and
dimensioned inside an inline-block.

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

CSS 2.1 test suite (RC3; October 27th 2010):
http://test.csswg.org/suites/css2.1/20101027/html4/toc.html

CSS 2.1 test suite contributors:
http://test.csswg.org/source/contributors/
Received on Friday, 19 November 2010 20:13:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 19 November 2010 20:13:51 GMT