- From: James Graham <jgraham@opera.com>
- Date: Tue, 20 Apr 2010 10:38:43 +0200
- To: Anne van Kesteren <annevk@opera.com>
- CC: Kris Krueger <krisk@microsoft.com>, "public-html-testsuite@w3.org" <public-html-testsuite@w3.org>
On 04/20/2010 08:24 AM, Anne van Kesteren wrote: > On Tue, 20 Apr 2010 15:20:18 +0900, Kris Krueger <krisk@microsoft.com> > 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 08:39:23 UTC