Re: [XHR] responseType "json"

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