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

RE: [CSS 2.1] Invalid test cases; 15 z-index applies to testcases

From: Gérard Talbot <css21testsuite@gtalbot.org>
Date: Tue, 27 Jul 2010 17:22:39 -0700
Message-ID: <475b249ed5cf7e00a470af5bb25d851c.squirrel@cp3.shieldhost.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 20 September 2010 17:52:02 GMT