RE: Test Case Approval Request

Given the size of the HTML5 spec, I would hope that many people contribute tests to the suite.
For the DOM tests that get submitted, I'd suggest the following as potential requirements.

* Simple Run (Just Load The Page)
* Pass/Fail Results are clear and consistent
* All the core parts (not tests live in a single js file, e.g. asserts)
* No complex design - hidden iframes, page load events, etc..


-----Original Message-----
From: James Graham [] 
Sent: Tuesday, April 20, 2010 1:39 AM
To: Anne van Kesteren
Cc: Kris Krueger;
Subject: Re: Test Case Approval Request

On 04/20/2010 08:24 AM, Anne van Kesteren wrote:
> On Tue, 20 Apr 2010 15:20:18 +0900, Kris Krueger <>
> wrote:
>> Just to make sure I understand your feedback...
>> You think that the test is valid and can help overall browser
>> interoperability looking at past browser implementations.
>> Though the title of the test needs to be more clear, call out that
>> it's a content attribute test rather than an interface test.
> Yeah, though it would probably be simpler to have a single test for all
> known content attributes on all known elements. You would then simply
> test with a few values on all of these (e.g. colors, URLs,
> space-separated items, simple tokens, etc.) and test whether they get
> normalized in some way. Should be quite simple to do with a few arrays
> and a loop.

Just as a matter of clarity, is the expectation that Microsoft will 
write a large number of tests using this framework and submit them? Or 
is the expectation that this will be the preferred framework for DOM 
test submissions from multiple parties? If the latter, I think it would 
be worthwhile to spend a few cycles iterating requirements / designs for 
testing DOM functionality. If it is the former then I think you are free 
to use whatever design you prefer (subject to it being easy to integrate 
with browser regression systems).

In either case it seems that there are a few potentially significant 
edge-case bugs in the current harness e.g. it fails to use strict 
equality for assertEquals and it doesn't cope well with NaN.

Received on Tuesday, 20 April 2010 14:34:20 UTC