Re: XHR responseArrayBuffer attribute: suggestion to replace "asBlob" with "responseType"

On Wed, Nov 10, 2010 at 2:05 PM, Chris Rogers <> wrote:
>> After discussion with Anne and James, I retract my support for a new
>> constructor.  I'm in favor of .responseType.
>> Specifically, .responseType would take values like "" (for legacy
>> treatment) / "text" / "document" / "arraybuffer" / "blob" / etc.  If
>> the value is "", then .responseText and .responseXML are filled
>> appropriately, while .response is empty.  Otherwise, .responseText and
>> .responseXML are empty (or throw or something), while .response
>> contains the value in the chosen format.  .responseType must be set at
>> some appropriately early time; after the response is received, changes
>> to .responseType are ignored or throw.
>> ~TJ
> So you prefer that .responseType take a string value as opposed to an
> integer enum value?  Darin Fisher had the idea that introspection of the
> supported values would be easier as an enum.

Yes, I think using an enum would be *extremely* verbose, particularly
given this particular API's name.  I don't want to see or type code


This is much better:

myXHR.responseType = "arraybuffer";


Received on Wednesday, 10 November 2010 23:01:54 UTC