DOMParser's parseFromString function and IE 9

When Internet Explorer 9 is running in Standards mode the DOMParser object is now available.

The DOMParser object allows one to convert a string of XML into a document object by calling the DOMParser's parseFromString function.

This article will focus only on the DOMParser object and will not do the standard feature detection tests that should be done for cross-browser compatibility (this code will break if IE 9 is not running in Standards mode or if you are using a previous version of IE).

If you are interested in seeing how to do proper feature detection tests for the DOMParser object, the following article has an example function called ConvertStringToXMLObject:
http://cggallant.blogspot.com/2011/03/xmlhttprequest-calls-when-in-ie-9.html

Something to be aware of with the DOMParser's parseFromString function is that the resulting XML document may have attributes that are rearranged compared to the attributes of the XML string that was passed in.

For example, if we have the following string of XML one would expect that the resulting XML document object would be an exact replica of the original XML string:

var sXML = "<TEST ID=\"124\" TITLE=\"TitleValue\" DATE=\"2011-02-24T00:00:00\" STATUS=\"Processing\" EMPNAME=\"Smith, Sam\" STATUSCODE=\"P\" ROWNUM=\"1\" />";

What has been discovered, however, is that if you pass the above XML string into the DOMParser's parseFromString function, the attributes in this case are completely reversed:

var dpParser = new DOMParser();
var xdDoc = dpParser.parseFromString(sXML, "text/xml");

// Grab the root 'Test' node from the document object and then
// loop through the attributes
var xnTest = xdDoc.getElementsByTagName("TEST")[0];
var xaAttrib = null;
var iAttribCount = xnTest.attributes.length;
for (var iIndex = 0; iIndex < iAttribCount; iIndex++){

// Grab the current attribute and display its name
xaAttrib = xnTest.attributes[iIndex];
alert(xaAttrib.nodeName);

}

The result shows that the XML attributes passed in are now in reverse order:

<TEST ROWNUM="1" STATUSCODE="P" EMPNAME="Smith, Sam" STATUS="Processing" DATE="2011-02-24T00:00:00" TITLE="TitleValue" ID="124" />

A bug was filed with Microsoft on this issue but, unfortunately, Microsoft has indicated that the parseFromString behavior is by design.

The best advice that can be given for this situation is to not iterate over the attributes using indexes and instead to grab the attribute values by name as in the following example:

var xnTest = xdDoc.getElementsByTagName("TEST")[0];
var sID = xnTest.getAttribute("ID");

XMLHttpRequest calls when in IE 9 Standards mode

With Internet Explorer 10 (IE 10), the issue described in this article has been fixed if the browser is using IE 10 Standards Mode.

With all versions of Internet Explorer, even when IE becomes more standards compliant, there are usually workarounds that are still needed.

Even though IE 9 is the most standards compliant Microsoft browser to date, there are still several things that have been discovered that we need to be aware of.

Feature detection tests should always test for W3C features first and fall back to IE specific features if the W3C feature is unavailable. For example, the following would be the feature detection code to use to create an XML object from a string of XML:

function ConvertStringToXMLObject(sXML) {

// Test for W3C feature
if (DOMParser) {

var dpDOMParser = new DOMParser();
return dpDOMParser.parseFromString(sXML, "text/xml");

} else { // IE 8 and previous or IE 9 when *not* in Standards mode...

var xdDoc = new ActiveXObject("Microsoft.XMLDOM");
xdDoc.loadXML(sXML);
return xdDoc;

}

}

When Standards mode is on, IE 9 now supports the DOMParser object. The issue with this, however, is that the XMLHttpRequest object still returns an MSXML ActiveX object from the reponseXML property no matter which document compatibility mode IE 9 is using.

The MSXML ActiveX XML object is not compatible with the DOMParser XML object and will result in a 'Type mismatch' error if you try to append the one XML object to the other.

The workaround for this issue is to pass the responseText property, from your XMLHttpRequest object, to your client-side XML object creation function so that you get an XML object of the proper type as in the following example:

function MakeServerSideCall(sURL, sPostData) {

var xhrRequest = GetXMLHttpRequestObject();
xhrRequest.open("POST", sURL, false);
xhrRequest.send(sPostData);

return ConvertStringToXMLObject(xhrRequest.responseText);

}


function GetXMLHttpRequestObject(){

var xhrRequest = null;

if (window.XMLHttpRequest) { xhrRequest = new XMLHttpRequest(); }
else if (window.ActiveXObject) { xhrRequest = new ActiveXObject("Microsoft.XMLHTTP"); }

return xhrRequest;

}

The following is a Microsoft article which talks about the DOMParser object, XMLSerializer object, as well as this workaround for the XMLHttpRequest object:
http://blogs.msdn.com/b/ie/archive/2010/10/15/domparser-and-xmlserializer-in-ie9-beta.aspx