I'd like to bring up an issue with the spec with regards to responseText + the new "json" responseType. Currently it is written that responseText should throw an exception if the responseType is not "" or "text". I would argue that responseText should also return the plain text when the type is "json".
Take the scenario of debugging an application, or an application that has a Error Reporting feature; If XHR.response returns "null", meaning the JSON payload was not successfully parsed and/or was invalid, there is no means to retrieve the plain text that caused the error. "null" is rather useless at that point. See my WebKit bug for more context: https://bugs.webkit.org/show_bug.cgi?id=73648 For legacy reasons, responseText and responseXML continue to work together despite the responseType that is set. In other words, a responseType of "text" still allows access to responseXML, and responseType of "document" still allows access to responseText. And it makes sense that this is so; if a strong-typed Document from responseXML is unable to be created, responseText is the fallback to get the payload and either debug it, submit it as an error report, etc. I would argue that "json" responseType would be more valuable if it behaved the same. Unlike the binary types (ArrayBuffer, Blob), "json" and "document" are backed by a plain text payload and therefore responseText has value in being accessible. If all we can get on a bad JSON response is "null", I think there is little incentive for anyone to use the "json" type when they can use "text" and JSON.parse it themselves. Comments, questions, and flames are welcomed! Thanks, Jarred