Anne van Kesteren wrote:
On Tue, 17 Jun 2008 10:29:12 +0200, Zhenbin Xu
<[EMAIL PROTECTED]> wrote:
Technically because all other XHR methods/properties throw exceptions
in case of state violation, exception for responseXML/responseText is
better.
The reason these don't throw an exception anymore is actually documented
on the public-webapi mailing list. Nobody else provided additional
information at the time:
http://lists.w3.org/Archives/Public/public-webapi/2008Feb/thread.html#msg94
Regarding parseError, since the parseError object is not part of DOM
Core and nobody but Internet Explorer supported it, it's not part of
XMLHttpRequest.
Agreed.
If we change DOM Core to say that documents with a
namespace well-formedness violation are represented by an empty Document
object with an associated parseError object I suppose we could update
XMLHttpRequest to that effect.
If we return null now people will use that to check for well-formedness
checks. If we in the next version of the spec then said that an empty
document with .parseError set should be returned those pages would break.
So if we are planning on doing the parse error thing then I think we
should define that an empty document is returned.
Though I think it's more friendly to JS developers to return null.
Otherwise they have to nullcheck both .responseXML as well as
.responseXML.documentElement in order to check that they have a valid
document.
And if I understand it right IE would have to be changed to be complient
with the spec no matter what since they currently return a non-empty
document.
/ Jonas
