On Wed, 30 May 2007 10:40:14 +0200, Alexey Proskuryakov
[EMAIL PROTECTED] wrote:
On 5/30/07 12:04 PM, Anne van Kesteren [EMAIL PROTECTED] wrote:
It turned out that there is already some code (Dashboard widgets) that
relies on Http-Equiv METAs being honored by XMLHttpRequest. This worked
in
* Anne van Kesteren [EMAIL PROTECTED] [Mon, 04 Jun 2007 16:35:50
+0200]:
On Wed, 30 May 2007 10:40:14 +0200, Alexey Proskuryakov
[EMAIL PROTECTED] wrote:
On 5/30/07 12:04 PM, Anne van Kesteren [EMAIL PROTECTED] wrote:
It turned out that there is already some code (Dashboard widgets)
that
On Wed, 30 May 2007 09:44:41 +0200, Alexey Proskuryakov
[EMAIL PROTECTED] wrote:
It turned out that there is already some code (Dashboard widgets) that
relies on Http-Equiv METAs being honored by XMLHttpRequest. This worked
in shipping Safari/WebKit by accident: all XHR content was passed
On 5/30/07 12:04 PM, Anne van Kesteren [EMAIL PROTECTED] wrote:
It turned out that there is already some code (Dashboard widgets) that
relies on Http-Equiv METAs being honored by XMLHttpRequest. This worked
in shipping Safari/WebKit by accident: all XHR content was passed
through an
On Mon, 26 Feb 2007 15:04:09 +0100, Alexey Proskuryakov
[EMAIL PROTECTED] wrote:
It is not really obvious to me why this is even desirable - isn't it
easier to serve as XHTML in cases when responseXML is needed? After all,
XMLHttpRequest is not a general purpose HTTP library, so we don't need
* Anne van Kesteren wrote:
I think it actually is a general purpose HTTP library, despite the name.
(For ECMAScript anyway.)
A general purpose HTTP library would need to, at the very least, allow
me to download bitmap graphics. As currently proposed, XHR can not.
--
Björn Höhrmann ·
On Wed, 28 Feb 2007 14:34:44 +0100, Bjoern Hoehrmann [EMAIL PROTECTED]
wrote:
I think it actually is a general purpose HTTP library, despite the name.
(For ECMAScript anyway.)
A general purpose HTTP library would need to, at the very least, allow
me to download bitmap graphics. As currently
On 2/26/07 3:21 PM, Anne van Kesteren [EMAIL PROTECTED] wrote:
But should we really make it be like that? Once HTML5 is there we probably
want .responseXML to work for text/html documents as well and we probably
want the encoding to be derived the same way HTML5 specifies it should be
On Wed, 28 Feb 2007 15:43:25 +0100, Alexey Proskuryakov
[EMAIL PROTECTED] wrote:
Another consideration: architecturally, it may be unwise to combine both
loading and parsing functionality in a single API.
Agreed, but that's how it is.
For XML parsing, DOM3 Load (or another dedicated API)
Anne van Kesteren schrieb:
For XML parsing, DOM3 Load (or another dedicated API) could provide
much more control. Obviously, we cannot remove responseXML from
XMLHttpRequest, but not adding more known formats sounds like a good
idea to me.
Is such control really needed? For most people
On Wed, 28 Feb 2007 18:57:10 +0100, Julian Reschke [EMAIL PROTECTED]
wrote:
Well, does any of the existing implementations support parsing HTML and
returning an XML DOM? And why would you want to do that in the first
place?
FWIW, there's no such thing as an XML DOM as far as browsers are
On 2/22/07 12:26 PM, Bjoern Hoehrmann [EMAIL PROTECTED] wrote:
You have a similar situation e.g. for text/css and text/html, where the
specifications similarily override their underlying protocols. It does
not strike me as very likely that implementers will implement the draft
so that
On Mon, 26 Feb 2007 11:29:28 +0100, Alexey Proskuryakov
[EMAIL PROTECTED] wrote:
In my testing, I have found that existing implementations already deduce
the charset for XHR response in a way that's drastically different from
normal page loading.
But should we really make it be like that?
On Feb 26, 2007, at 4:21 AM, Anne van Kesteren wrote:
On Mon, 26 Feb 2007 11:29:28 +0100, Alexey Proskuryakov ap-
[EMAIL PROTECTED] wrote:
In my testing, I have found that existing implementations already
deduce the charset for XHR response in a way that's drastically
different from
On Mon, 26 Feb 2007 13:58:24 +0100, Maciej Stachowiak [EMAIL PROTECTED]
wrote:
I think it might be wiser to add a .responseHTML that works for HTML
documents in the future, since you can test for a new property from
script but you can't test for new behavior of an existing property. And
On Thu, 22 Feb 2007 10:26:01 +0100, Bjoern Hoehrmann [EMAIL PROTECTED]
wrote:
For responseText the current draft says:
If the response includes a Content-Type understood by the user agent
the characters are encoded following the relevant media type
specification, with the exception
Hi,
For responseText the current draft says:
If the response includes a Content-Type understood by the user agent
the characters are encoded following the relevant media type
specification, with the exception that the rule in the final paragraph
of section 3.7.1 of [RFC2616], and the
17 matches
Mail list logo
