- From: Gérard Talbot <css21testsuite@gtalbot.org>
- Date: Tue, 27 Jul 2010 17:22:39 -0700
- To: "Arron Eicholz" <Arron.Eicholz@microsoft.com>
- Cc: "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>
> Here is an update for the Invalid Test cases list. (...) > I think we should just remove these cases, any objections?: > (I plan to remove cases on 7/29 if there are no objections.) > http://test.csswg.org/suites/css2.1/20100701/html4/active-selector-000.htm > http://test.csswg.org/suites/css2.1/20100701/html4/c5504-mrgn-l-002.htm > http://test.csswg.org/suites/css2.1/20100701/html4/c61-phys-len-000.htm > http://test.csswg.org/suites/css2.1/20100701/html4/floats-107.htm > http://test.csswg.org/suites/css2.1/20100701/html4/units-007.htm Arron, You may remove these 5 testcases. Just one comment on floats-107.htm though. The testcase may be wrong but its underlying idea and purpose may be correct. So, I created Stacking levels of positioned elements versus floated elements http://www.gtalbot.org/BrowserBugsSection/css21testsuite/z-index-stack-003.html and floats - zero height empty float http://www.gtalbot.org/BrowserBugsSection/css21testsuite/floats-107-gt.html and this latter one is precisely what Ian Hickson wanted to test: does a zero height empty float occupies an horizontal space on a line? and I do not know the answer to such question. All browsers seem to say "no" but I can not find the statement in the spec which could back me up on this. Ian Hickson thought "yes" with his comment /* height effectively 0, but still taking room up on its "line" */ Z-index applies to testcases ============================ http://test.csswg.org/suites/css2.1/20100701/html4/z-index-applies-to-001.htm to http://test.csswg.org/suites/css2.1/20100701/html4/z-index-applies-to-015.htm are all wrong, incorrect IMO for 2 reasons: 1- position: relative on sub-table elements is no good: " 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. " http://www.w3.org/TR/CSS21/visuren.html#choose-position 2- In all those 15 testcases, the tested element always precedes the overlapping <div id="zindex"></div> (green background) which is set to z-index: auto and the z-index property of such tested element (red background) is set to -1. So, these testcases never actually test if the tested element actually supports a z-index declaration because even if it did not, the next element in code order is set to auto. "Boxes with the same stack level in a stacking context are stacked back-to-front according to document tree order." So, the next element would overlap (paint in front of) the preceding one anyway, all the times. The logic of those 15 testcases is wrong. You would want the tested element to have a greater stacking level than 'z-index: auto', to have a green background and to precede in the code another element with a red background. Maybe I'm not explaining, wording this clearly. But I assure you that those 15 z-index-applies-to-0xx.htm should be relooked. I even found a DHTML bug in IE8 with z-index while investigating all this: http://www.gtalbot.org/BrowserBugsSection/css21testsuite/z-index-dynamic-001.html IMO, it should be added into the test suite. regards, Gérard -- Contributions to the CSS 2.1 test suite: http://www.gtalbot.org/BrowserBugsSection/css21testsuite/ CSS 2.1 test suite (beta 1; July 1st 2010): http://test.csswg.org/suites/css2.1/20100701/html4/toc.html CSS 2.1 test suite contributors: http://test.csswg.org/source/contributors/
Received on Wednesday, 28 July 2010 00:23:15 UTC