- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Wed, 27 Oct 2010 15:34:06 -0400
- To: Michael Nordman <michaeln@google.com>
- CC: Geoffrey Garen <ggaren@apple.com>, Darin Fisher <darin@chromium.org>, Chris Rogers <crogers@google.com>, Web Applications Working Group WG <public-webapps@w3.org>, Anne van Kesteren <annevk@opera.com>, Eric Uhrhane <ericu@google.com>, Alexey Proskuryakov <ap@webkit.org>, Chris Marrin <cmarrin@apple.com>, jorlow@google.com, jamesr@chromium.org
On 10/27/10 3:23 PM, Michael Nordman wrote: > Darin mentioned it earlier in this thread, having XHR return the raw > data and providing other interfaces to interpret/decode the raw data > into strings/xmlDocs. I like that decomposition. If we were designing from scratch, yes. Or is the proposal that we introduce the up-front modal switch and provide such APIs to allow consumers who want bytes-or-string to say they want bytes but then manually create the string later? Note, by the way, that for XML and HTML types, one is required (per current XHR spec) to instantiate an XML or HTML parser, respectively, to produce the responseText (because the data can declare its own encoding in things like <meta> tags). I'm not sure whether that complicates the other interfaces being proposed.... I guess they could do that under the hood. But they point is they'd need to know the MIME type, not just the data. -Boris
Received on Wednesday, 27 October 2010 19:34:41 UTC