Re: [XHR2] responseText for text/html before the encoding has stabilized

On Sun, Oct 2, 2011 at 12:08 AM, Anne van Kesteren <annevk@opera.com> wrote:
> On Sat, 01 Oct 2011 22:09:47 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
>>>
>>> If we change how determining encoding works between default, "text", and
>>> "document", we should really start throwing for responseText and
>>> responseXML when responseType is not the default to indicate that is
>>> different.
>>
>> Why? What problem are you trying to solve?
>
> I think it would be confusing for responseText to give different results for
> "" and "text". The whole point was that since it behaved the same it did not
> matter. If we make it behave differently, that invariant is gone, and it
> seems better to not expose it at all.

Is it really that much more confusing than the fact that .response
gives different results depending on the value of .responseType?

Additionally it feels like optimizing for the more rare case when
.responseText is used to load unparsed HTML/XML contents, rather than
textual contents.

The advantage I can see of making text responses available through
.responseText is that it'll make it easier to transition to using
.responseType. I.e. if you have a large JS codebase which loads
non-XML data through XMLHttpRequests, you can simply set
.responseType="text". In browsers that doesn't support .responseType
this is a no-op. In browsers that do support .responseType the browser
won't waste time checking if the response should be parsed as a
document. In both cases you can read the result through .responseText.

/ Jonas

Received on Monday, 3 October 2011 05:50:14 UTC