On Wed, 05 Apr 2006 03:22:36 +0200, Cameron McCormack <[EMAIL PROTECTED]>
wrote:
[...]
alternative, DOMImplementation?).
Yeah, not sure which one is better... I'm also not sure whether to do it
for version 1.0 or version 2.0 just wanted to make sure it's not
impossible to do later on.
Is it worth specifying exactly how "In ECMAScript, an instance of
XMLHttpRequest can be created using the XMLHttpRequest() constructor"?
If so, perhaps it should be something along these lines:
[...]
This is somewhat verbose, but is certainly better than the type of text
in http://www.w3.org/TR/DOM-Level-2-Core/ecma-script-binding.html, for
example.
Thanks for that! I don't think it will be reflected in the First Public
Working Draft, but we'll look into it and if it's correct probably include
it in a later version.
While XMLHttpRequest, as a host object, does not have to behave like
native objects, for consistency I think it is advantageous if it does.
Opera seems to implement it mostly as I've described. Mozilla is a
little different, in that the XMLHttpRequest constructor is not a
function and also does not have a length property. The XMLHttpRequest
constructor's prototype property is ReadOnly in Opera, but not in
Mozilla. I haven't tested other UAs.
Interesting, we should probably look into this.
[re onreadystatechange]
What if languages don't have functions? Perhaps this should be an
EventListener?
An EventListener has the advantage of being an existing interface, but
somehow it seems weird to use it if XHR isn't an EventTarget.
I agree. I actually want XHR to be an EventTarget as well because it makes
sense, but the only problem is that there's no implementation for that...
There's also the issue of what you pass as the Event object to
handleEvent.
I notice that Mozilla recently made a decision wrt this
(https://bugzilla.mozilla.org/show_bug.cgi?id=198595).
Yeah, there should be an open issue on that. I'd like `this` to return the
XMLHttpRequest object. Opera does that. Internet Explorer and Safari
return the Window object. Mozilla returns the Function object you passed
to onreadystatechange...
If XHR were an
EventTarget that you could do an addEventListener on as well as assign
to onreadystatechange, and have onreadystatechange just be an
ES-specific property, that would make sense to me.
Not sure if it has to be ES-specific, but yes. It's like:
obj.onload
obj.onerror
... etc. When people use that in most UAs you can also do:
obj.addEventListener('load', ...)
obj.addEventListener('error', ...)
...
[re readyState == 3]
What about HEAD requests?
Perhaps the wording should be something like:
Immediately [after] all HTTP headers have been received.
And also mention somewhere that HEAD requests would run
onreadystatechange for readyState == 4 immediately after
readyState == 3.
Yeah, something like that.
[re open's method argument]
What about PUT and DELETE?
I don't see any reason (except for the stated goal of finding a common
baseline on all implementations) to exclude some HTTP headers.
You mean methods? What about methods other specifications are introducing?
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
