Re: No arguments to XMLHttpRequest.send (ACTION-58)

"Jonas Sicking" <jonas@sicking.cc>
> We simply follow DOM convention and have all the parameters to the 
> function required even if they in some cases are not needed.

The object isn't even internally consistent, one method has optional 
parameters, another on the same object doesn't, I'd say that behaviour was 
broken, it's not very importantly broken as poor scripters can work around 
it, but it is still broken behaviour if intentional, rather than simply a 
bug.

> So authors will have to provide an argument for a significant time if they 
> want to work in the major browsers.

Which is fine, but a specification is for what an implementor needs to 
implement, not what an author needs to code.

> Another problem is how do you write the spec the other way around? We 
> can't say that you MUST make the argument optional and at the same time 
> say that you MAY require the argument.

You don't need to, you simply imclude a note to authors highlighting the 
behaviour in legacy UA's so they SHOULD include a parameter.   I realise 
this would make FireFox 1.5 non-conformant which would be a shame, but I 
think it's likely that many other user agents will be non-conformant too in 
many areas.  IE6 in creation methods and non-http status codes for example.

> > I am more
>> concerned about implementors not making the mistake.
>
> If this is the only concern then I think we could just mention in the spec 
> that "implementors are advised to make this argument optional since there 
> is a lot of content on the web today that calls the function with no 
> arguments".

I don't want an advised I want at the very least a SHOULD, and preferably a 
MUST.

You're working from this from a perspective "I don't want Mozilla to be 
marked non-conformant", I'm working from a perspective of "I don't want all 
my content to be marked non-conformant".  If we agree that going forward 
optional parameters are correct, then I think it's better to deal with the 
non-conformance in one legacy UA at REC stage, than it is to invalidate lots 
of web-content in the future.

I can however live with Maciej's wording in:
http://www.w3.org/mid/6F06CBA2-3A4E-486E-BA02-47A14E092BFF@apple.com
Which gets around the FF1.5 being otherwise non-conformant? Would that be 
acceptable to you Jonas?

Cheers,

Jim.

Received on Sunday, 5 March 2006 12:35:17 UTC