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

Re: RC1 : 1st preliminary review report: list of 69 incorrect testcases

From: Gérard Talbot <css21testsuite@gtalbot.org>
Date: Sat, 25 Sep 2010 17:17:35 -0700
Message-ID: <1f316b9aa638740abf718f25b6569616.squirrel@cp3.shieldhost.com>
To: "Boris Zbarsky" <bzbarsky@MIT.EDU>
Cc: "Anne van Kesteren" <annevk@opera.com>, "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>

> On 9/25/10 4:36 PM, "Gérard Talbot" wrote:
>> My original point 14- [1] was about duplicated id in those testcases -
>> many testcases - and that those testcases were relying on a script
>> function being able to iterate through the collection of same,
>> identical
>> id-ed elements ... which is not an assured thing to happen.
>
> They were relying on no such thing.

Okay <nod>. I see what you mean now.


> They _were_ relying on
> getElementById returning the first element with that id in the document.

Not all browsers have (or should be assumed to have) the exact, same and
correct implementation of getElementById. Anyway, this is a CSS test
suite having testcases on CSS; testcases aiming at testing CSS
compliance.


>> The other points were presented as "other smaller problems" which
>> could
>> be fixed at the same time. My perspective is: if you are going to
>> update
>> a testcase (furthermore a batch of testcases; there are 208 testcases
>> on
>> table-anonymous-objects !), why not fix at the same time all of the
>> [admittedly] smaller issues which are fixable and which were defined
>> in
>> the wiki wrt test format [2] and in CSS2.1 Test Case Authoring
>> Guidelines (section 3.4) [3]? With an advanced text editor, it is very
>> easy to make changes/updates to a batch of testcases.
>
> It's also very easy to introduce bugs making such batch updates.  Some
> of these testcases are very sensitive to things like exact whitespace,
> etc.

Boris, you are the best person to make such assessment, to evaluate the
trade-offs, the risks, the time involved, the availability of
reliable-precise text editors to carry up the changes, etc.. and then to
decide if/how/why a code change is required (and realistically feasible)
in the precise issues I have presented to you. Maybe you know (and I do
not know) that it is too late or too complex or too long now to make
changes or some changes or that particular change.

Ideally, I should never have to report a validation markup error, a DOM
or script issue, an RFC issue or any test format guideline related
issue.

Generally speaking, I try to only review the testcases from a CSS
perspective and from a testcase perspective. I try to propose
alternatives or replacements which can smooth or reduce
efforts/time/energy to improve or upgrade or correct reviewed testcases.
And ultimately, someone else besides me has the final word/veto wrt
issues like that.

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

CSS 2.1 test suite (RC1; September 17th 2010):
http://test.csswg.org/suites/css2.1/20100917/html4/toc.html

CSS 2.1 test suite contributors:
http://test.csswg.org/source/contributors/
Received on Sunday, 26 September 2010 00:18:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 26 September 2010 00:18:21 GMT