Re: [XMLHttpRequest-tests] Test should be for compliance with actual spec (#974)

@annevk How solid the consensus was is sort of irrelevant for such a minor change - IMO real issue is that while you may be happy to leave things up in the air and be undecided about what the spec should say for a while, we'd like to nail things down to have something "shippable" - both tests and the W3C spec, and we got a bit confused when you seemed to change your mind. We just need to talk it over and figure it out, I guess.

By "consolidate" the exceptions, I guess you mean being consistent throughout the spec? If I try to pull out all instances of  /"[^"]+"\s*exception/ from the spec text and do some stats I get this:
```json
{
  "SyntaxError": 8,
  "SecurityError": 2,
  "InvalidAccessError": 9,
  "InvalidStateError": 19,
  "TimeoutError": 1
}
```
(We also have NetworkError and AbortError that are used in the text in ways that evaded that regexp).

If we replaced "SyntaxError" with "TypeError" in the above list (it's used for argument validation for overrideMimeType() , open() and setRequestHeader()), in what way would it be less/more consistent with 

a) the rest of the spec
b) other TypeError usage in JS
c) where WebIDL or ES6 is going

?

We can make this decision based on what most implementations do, or what we think makes more sense and is consistent with the rest of the platform - but I really see no reason we should postphone the decision and just say "the spec might change". I guess I just don't really understand your mental roadmap here. :)

View on GitHub: https://github.com/w3c/web-platform-tests/pull/974#issuecomment-42950787

Received on Tuesday, 13 May 2014 12:57:12 UTC