"Anne van Kesteren" <[EMAIL PROTECTED]>
I don't see why responseText MUST be null other than in readyState 3 or
4, why not undefined (e.g. if the firing of the 2 is delayed for some
reason then data could be available) Equally MUST on 3 is incompatible
with existing implementations.
It's never null. If the firing of the 2 is delayed, isn't that just a bug?
No, we're not mandating that events fire in realtime - we can't as ES is
single threaded etc.
The "MUST on 3" is incompatible with existing implementations in what way?
MS's XHR implementation throws an error on 3.
alert( ) isn't defined anywhere, traditionally print has been used as a
dummy function in ES code.
Any pointers of its use?
The ES spec, just changing alert to print...
by data.xmlEncoding, if specified and supported, or UTF-8 otherwise
Makes some sense to me...
I still don't see the point of the restriction at all, and inputEncoding
would be a better option than xmlEncoding - if we're assuming the server
knows the best format for a document serialisation, but I don't see the
point of requiring such behaviour.
> Responded to this one already. In addition, we now have an open issue on
it.
Cheers!
Jim.
