- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Wed, 10 Nov 2010 15:00:59 -0800
- To: Chris Rogers <crogers@google.com>
- Cc: David Flanagan <david@davidflanagan.com>, Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org, Jonas Sicking <jonas@sicking.cc>, Maciej Stachowiak <mjs@apple.com>, Geoffrey Garen <ggaren@apple.com>, Darin Fisher <darin@chromium.org>, Anne van Kesteren <annevk@opera.com>, Eric Uhrhane <ericu@google.com>, michaeln@google.com, Alexey Proskuryakov <ap@webkit.org>, jorlow@google.com, jamesr@chromium.org
On Wed, Nov 10, 2010 at 2:05 PM, Chris Rogers <crogers@google.com> 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 like: myXHR.responseType = XMLHttpResponse.RESPONSETYPE_ARRAYBUFFER; This is much better: myXHR.responseType = "arraybuffer"; ~TJ
Received on Wednesday, 10 November 2010 23:01:54 UTC