It would be really nice if we could move forward with this thread.
My preference is still to not do any HTML/XML specific processing when
.responseType is set to anything other than or document. This
allows us to make encoding handling consistent for text and a
possible future incremental text
On Mon, Nov 7, 2011 at 9:57 AM, Jonas Sicking jo...@sicking.cc wrote:
It would be really nice if we could move forward with this thread.
I was planning on reporting back when I have something that passes all
mochitests. This has been delayed by other stuff. Particularly fallout
from the new View
On Mon, Nov 7, 2011 at 7:43 AM, Henri Sivonen hsivo...@iki.fi wrote:
Also, the current spec leads to quite strange results if we end up
supporting more text-based formats directly in XHR. For example in
Gecko we've added experimental support for parsing into JSON. If we
added this to a future
On Fri, Sep 30, 2011 at 8:05 PM, Jonas Sicking jo...@sicking.cc wrote:
Unless responseType== or responseType==document I don't think we
should do *any* HTML or XML parsing. Even the minimal amount needed to
do charset detection.
I'd be happy to implement it that way.
For responseType==text
On Sat, 01 Oct 2011 22:09:47 +0200, Jonas Sicking jo...@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.
On Sun, Oct 2, 2011 at 12:08 AM, Anne van Kesteren ann...@opera.com wrote:
On Sat, 01 Oct 2011 22:09:47 +0200, Jonas Sicking jo...@sicking.cc wrote:
If we change how determining encoding works between default, text, and
document, we should really start throwing for responseText and
On Fri, 30 Sep 2011 21:41:39 +0200, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Sep 30, 2011 at 12:11 PM, Anne van Kesteren ann...@opera.com
wrote:
On Fri, 30 Sep 2011 19:26:48 +0200, Jonas Sicking jo...@sicking.cc
wrote:
Hmm.. I looked through archives but can't find any such decision.
On Fri, 30 Sep 2011 20:05:41 +0200, Ian Hickson i...@hixie.ch wrote:
I agree that the reloading alternative is even worse. What about just
relying on the Content-Type charset= and defaulting to UTF-8 if it
isn't there, and not doing any in-page stuff?
That would work for me. It seems Jonas
On Sat, Oct 1, 2011 at 12:03 AM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 30 Sep 2011 21:41:39 +0200, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Sep 30, 2011 at 12:11 PM, Anne van Kesteren ann...@opera.com
wrote:
On Fri, 30 Sep 2011 19:26:48 +0200, Jonas Sicking jo...@sicking.cc
FWIW, I am waiting for http://www.w3.org/Bugs/Public/show_bug.cgi?id=14284
to be fixed in HTML before making changes to XMLHttpRequest.
On Thu, 29 Sep 2011 13:49:17 +0200, Henri Sivonen hsivo...@iki.fi wrote:
It seems to me that all these cannot be true:
* responseText and responseXML use
On Fri, Sep 30, 2011 at 3:04 PM, Anne van Kesteren ann...@opera.com wrote:
I do not see why text and moz-chunked-text have to be the same. Surely
we do not want XML encoding detection to kick in for chunks.
Does text and default need to be the same for responseText for
text/html and XML types?
On Fri, 30 Sep 2011 14:29:32 +0200, Henri Sivonen hsivo...@iki.fi wrote:
On Fri, Sep 30, 2011 at 3:04 PM, Anne van Kesteren ann...@opera.com
wrote:
I do not see why text and moz-chunked-text have to be the same.
Surely we do not want XML encoding detection to kick in for chunks.
Does text
On Fri, Sep 30, 2011 at 3:35 PM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 30 Sep 2011 14:29:32 +0200, Henri Sivonen hsivo...@iki.fi wrote:
On Fri, Sep 30, 2011 at 3:04 PM, Anne van Kesteren ann...@opera.com
wrote:
I do not see why text and moz-chunked-text have to be the same.
On Fri, 30 Sep 2011 14:40:09 +0200, Henri Sivonen hsivo...@iki.fi wrote:
responseType is a newish feature. If it's OK for responseType ==
chunked-text to use encoding determination rules that differ from
responseType == or responseType == document, why should
responseType == text have to be
On Fri, Sep 30, 2011 at 5:40 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Fri, Sep 30, 2011 at 3:35 PM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 30 Sep 2011 14:29:32 +0200, Henri Sivonen hsivo...@iki.fi wrote:
On Fri, Sep 30, 2011 at 3:04 PM, Anne van Kesteren ann...@opera.com
wrote:
On Fri, Sep 30, 2011 at 5:47 AM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 30 Sep 2011 14:40:09 +0200, Henri Sivonen hsivo...@iki.fi wrote:
responseType is a newish feature. If it's OK for responseType ==
chunked-text to use encoding determination rules that differ from
responseType
On Fri, 30 Sep 2011, Anne van Kesteren wrote:
FWIW, I am waiting for
http://www.w3.org/Bugs/Public/show_bug.cgi?id=14284 to be fixed in HTML
before making changes to XMLHttpRequest.
So... the prescanning is generally considered optional (the only benefit
really is that it avoids reloads in
On Fri, 30 Sep 2011 19:26:48 +0200, Jonas Sicking jo...@sicking.cc wrote:
Hmm.. I looked through archives but can't find any such decision.
It's not how Gecko works, but I haven't tried webkit.
http://lists.w3.org/Archives/Public/public-webapps/2010OctDec/0812.html
Kind of weird that Gecko
On Fri, Sep 30, 2011 at 12:11 PM, Anne van Kesteren ann...@opera.com wrote:
On Fri, 30 Sep 2011 19:26:48 +0200, Jonas Sicking jo...@sicking.cc wrote:
Hmm.. I looked through archives but can't find any such decision.
It's not how Gecko works, but I haven't tried webkit.
http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#text-response-entity-body says:
The text response entity body is a DOMString representing the
response entity body. and If charset is null and mime is text/html
follow the rules set forth in the HTML specification to determine the
character encoding.
20 matches
Mail list logo
