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

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

From: Arron Eicholz <Arron.Eicholz@microsoft.com>
Date: Thu, 2 Dec 2010 02:27:32 +0000
To: "css21testsuite@gtalbot.org" <css21testsuite@gtalbot.org>
CC: "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>
Message-ID: <07349ECFC3608F48BC3B10459913E70B102F9308@TK5EX14MBXC140.redmond.corp.microsoft.com>
On Friday, November 19, 2010 12:13 PM Gérard Talbot wrote: 
> what they are supposed to test
> 
> 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.

Fixed both cases.

--
Thanks,
Arron Eicholz
Received on Thursday, 2 December 2010 02:30:14 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 2 December 2010 02:42:44 GMT