W3C home > Mailing lists > Public > public-webapi@w3.org > March 2006

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

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 02 Mar 2006 17:13:29 -0800
Message-ID: <44079839.4080002@sicking.cc>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Jim Ley <jim@jibbering.com>, Web APIs WG <public-webapi@w3.org>

>>> If the audience of the specification is users (which I don't think it 
>>> is) and we do require it then the spec also needs to have an answer 
>>> to the question of "why must I pass null?".    I don't think "buggy 
>>> implementations" is an answer to that.
>> While most authors won't read the spec I think some will. And more 
>> importantly, the copy-chain has to start somewhere, probably at a 
>> tutorial or reference site. And people writing those I'd think are 
>> more likely to look at the spec.
> I think the first version of the spec should limit itself to an 
> interoperable subset of XMLHttpRequest that works in most major UAs. If 
> there is some critical extra feature and someone responsible for that 
> implementation can be convinced to add it, we could consider that as well.
> For things that some but not all UAs implement, and that we'd like to 
> require in a future version, we can add an informative note, or make it 
> a MAY or OPTIONAL level requirement.
> How does that sound as a general approach?
> I thinkingthe no-arg version of send() would fall under this category. 
> It does seem like something we want eventually, but could be MAY-level 
> or an informative "some implementations allow this" note for 
> XMLHttpRequest 1.0.

So you're suggesting that we make the argument required, but say that 
implementations MAY make it optional?

I would be probably be ok with that, but I don't quite see the point 
with it since any feature we don't specifically forbid can be added by 
any implementation.

>> I'd suspect not nearly as often as .send(). I believe safari was the 
>> only major browser that didn't support it, and if the safari team 
>> wants them removed for now I could live with that.
> We do have getResponseHeader and getAllResponseHeaders in Safari.

Then I don't remember which browser it was where we couldn't get it to 
work. I guess we'll find out during testing what exactly works where.

/ Jonas
Received on Friday, 3 March 2006 01:11:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:20 UTC