Re: [whatwg] Implement XMLHttpRequest interface subset onHTMLDocument
On Thu, 30 Oct 2008 08:21:10 +0100, Weston Ruter
[EMAIL PROTECTED] wrote:
I have an amendment to my proposal. There was a
posthttp://ajaxian.com/archives/language-jsonp-serviceon Ajaxian
today about a Language JSONP Service which calculates the
users language based on browser headers. This seems like a terrible
workaround since the Accept-Language header is sent from the same browser
that the script is running in; a script shouldn't have to make an HTTP
request just to find out what the browser's request headers are.
Did you read what kriszyp wrote in a comment to that post?
Therefore, I propose that in addition to implementing on HTMLDocument the
XMLHttpRequest interface subset I initially suggested, I see that it
would also be very useful for a script to obtain the request headers
that were
sent which resulted in the current document as the response. The current
version of XMLHttpRequest hints to a future version including a
getRequestHeader() method, a method which would complement
getResponseHeader(); there could also be a getAllRequestHeaders() method
that would correspond to the existing getAllResponseHeaders() method.
(Obviously it would not make sense to implement the setRequestHeader()
method.)
If these two methods ( getRequestHeader() and getAllRequestHeaders() )
were
implemented, then there would be no need for a Language JSONP Service
because there would be a better way to get the same result synchronously
without any HTTP request, for example:
document.getRequestHeader('Accept-Language')
I think we need more use cases than just this (especially since this one
seems addressed already) to consider this.
--
Anne van Kesteren
http://annevankesteren.nl/
http://www.opera.com/
Re: [whatwg] Implement XMLHttpRequest interface subset onHTMLDocument
On Wed, Dec 10, 2008 at 3:01 PM, Anne van Kesteren [EMAIL PROTECTED] wrote: On Thu, 30 Oct 2008 08:21:10 +0100, Weston Ruter [EMAIL PROTECTED] wrote: I have an amendment to my proposal. There was a posthttp://ajaxian.com/archives/language-jsonp-serviceon Ajaxian today about a Language JSONP Service which calculates the users language based on browser headers. This seems like a terrible workaround since the Accept-Language header is sent from the same browser that the script is running in; a script shouldn't have to make an HTTP request just to find out what the browser's request headers are. Did you read what kriszyp wrote in a comment to that post? Yes, and the answer to his question is: yes, there is a difference. First, those client-side properties give you one lang code only, which is clearly not enough for conneg. Let's say I have a GWT application available in dutch and english, where dutch is the default language (i.e. prefered over english). My navigator.language returns fr, but my Accept-Language reads fr-fr, fr, en. With navigator.language only, I'd have the dutch version, with Accept-Language I'd have the english one. Second, these client-side properties return the UI language, which is different from the user-preferred language. FF3.1b2 is now available in many languages but before that, only english was available. navigator.language in this case would return en, despite me having changed Accept-Language to fr-fr, fr, en. -- Thomas Broyer
Re: [whatwg] Implement XMLHttpRequest interface subset onHTMLDocument
On Wed, Dec 10, 2008 at 6:01 AM, Anne van Kesteren [EMAIL PROTECTED] wrote:
I think we need more use cases than just this (especially since this one
seems addressed already) to consider this.
I agree we need more use cases. You understand that the Accept-Language
header is just one example of a header that needs to be read via scripting;
the use case addressed by Language JSONP Service highlights the need for
getRequestHeaders() since its solution is an inefficient (although clever)
hack. Ideally, scripts should be able to access all of the request and
response headers.
Another use case would be getting the Accept header to detect if the
client can be served XHTML.
Weston
On Wed, Dec 10, 2008 at 6:01 AM, Anne van Kesteren [EMAIL PROTECTED] wrote:
On Thu, 30 Oct 2008 08:21:10 +0100, Weston Ruter
[EMAIL PROTECTED] wrote:
I have an amendment to my proposal. There was a
posthttp://ajaxian.com/archives/language-jsonp-serviceon Ajaxian
today about a Language JSONP Service which calculates the
users language based on browser headers. This seems like a terrible
workaround since the Accept-Language header is sent from the same browser
that the script is running in; a script shouldn't have to make an HTTP
request just to find out what the browser's request headers are.
Did you read what kriszyp wrote in a comment to that post?
Therefore, I propose that in addition to implementing on HTMLDocument the
XMLHttpRequest interface subset I initially suggested, I see that it would
also be very useful for a script to obtain the request headers that were
sent which resulted in the current document as the response. The current
version of XMLHttpRequest hints to a future version including a
getRequestHeader() method, a method which would complement
getResponseHeader(); there could also be a getAllRequestHeaders() method
that would correspond to the existing getAllResponseHeaders() method.
(Obviously it would not make sense to implement the setRequestHeader()
method.)
If these two methods ( getRequestHeader() and getAllRequestHeaders() )
were
implemented, then there would be no need for a Language JSONP Service
because there would be a better way to get the same result synchronously
without any HTTP request, for example:
document.getRequestHeader('Accept-Language')
I think we need more use cases than just this (especially since this one
seems addressed already) to consider this.
--
Anne van Kesteren
http://annevankesteren.nl/
http://www.opera.com/
Re: [whatwg] Implement XMLHttpRequest interface subset onHTMLDocument
I have an amendment to my proposal. There was a
posthttp://ajaxian.com/archives/language-jsonp-serviceon Ajaxian
today about a Language JSONP Service which calculates the
users language based on browser headers. This seems like a terrible
workaround since the Accept-Language header is sent from the same browser
that the script is running in; a script shouldn't have to make an HTTP
request just to find out what the browser's request headers are.
Therefore, I propose that in addition to implementing on HTMLDocument the
XMLHttpRequest interface subset I initially suggested, I see that it would
also be very useful for a script to obtain the request headers that were
sent which resulted in the current document as the response. The current
version of XMLHttpRequest hints to a future version including a
getRequestHeader() method, a method which would complement
getResponseHeader(); there could also be a getAllRequestHeaders() method
that would correspond to the existing getAllResponseHeaders() method.
(Obviously it would not make sense to implement the setRequestHeader()
method.)
If these two methods ( getRequestHeader() and getAllRequestHeaders() ) were
implemented, then there would be no need for a Language JSONP Service
because there would be a better way to get the same result synchronously
without any HTTP request, for example:
document.getRequestHeader('Accept-Language')
Weston
On Wed, Oct 29, 2008 at 12:45 PM, Kristof Zelechovski [EMAIL PROTECTED]
wrote:
Providing the original document tree before transformation in
HTMLDocument.responseXML makes sense. In that case, the Document returned
should be immutable, just as a DOMString is; I am not sure how to declare
it in IDL.
Chris
--
*From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of
*Weston Ruter
*Sent:* Wednesday, October 29, 2008 8:35 PM
*To:* Kristof Zelechovski
*Cc:* [EMAIL PROTECTED]; Ian Hickson; Anne van Kesteren
*Subject:* Re: [whatwg] Implement XMLHttpRequest interface subset
onHTMLDocument
This is not completely strange or unexpected construct, since window ==
window.self.
Furthermore, having a HTMLDocument.responseXML would be useful in the case
that an XSLT stylesheet outputs HTML, plain text, or something else; in such
a case, it would be very useful to get the original responseXML. Note that I
don't envision this responseXML being any sort of shadow DOM; I mean, if
XSLT did transform the XML data, making a change to responseXML would not
cause the XSLT engine to re-parse the updated responseXML. Maybe this would
be useful, but it seems overly complicated.
On Wed, Oct 29, 2008 at 12:26 PM, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
The meaning of HTMLDocument.responseXML looks a bit strange and
unexpected: a property of an object bound to the object itself by
definition. I would suggest leaving that one out.
Chris
--
*From:* [EMAIL PROTECTED] [mailto:
[EMAIL PROTECTED] *On Behalf Of *Weston Ruter
*Sent:* Wednesday, October 29, 2008 8:19 PM
*To:* Kristof Zelechovski
*Cc:* [EMAIL PROTECTED]; Ian Hickson; Anne van Kesteren
*Subject:* Re: [whatwg] Implement XMLHttpRequest interface subset
onHTMLDocument
If the interface were implemented as-is, document.responseXML would just be
a reference back to the document object.
So if the document is XML, then document === document.responseXML
On Wed, Oct 29, 2008 at 12:14 PM, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
What should the property HTMLDocument.responseXML represent?
Chris
Re: [whatwg] Implement XMLHttpRequest interface subset onHTMLDocument
The meaning of HTMLDocument.responseXML looks a bit strange and
unexpected: a property of an object bound to the object itself by
definition. I would suggest leaving that one out.
Chris
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Weston Ruter
Sent: Wednesday, October 29, 2008 8:19 PM
To: Kristof Zelechovski
Cc: [EMAIL PROTECTED]; Ian Hickson; Anne van Kesteren
Subject: Re: [whatwg] Implement XMLHttpRequest interface subset
onHTMLDocument
If the interface were implemented as-is, document.responseXML would just be
a reference back to the document object.
So if the document is XML, then document === document.responseXML
On Wed, Oct 29, 2008 at 12:14 PM, Kristof Zelechovski
[EMAIL PROTECTED] wrote:
What should the property HTMLDocument.responseXML represent?
Chris
_
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Weston Ruter
Sent: Wednesday, October 29, 2008 8:06 PM
To: [EMAIL PROTECTED]
Cc: Ian Hickson; Anne van Kesteren
Subject: [whatwg] Implement XMLHttpRequest interface subset on HTMLDocument
I realized that the HTTP response headers exposed in the HTMLDocument
http://www.w3.org/html/wg/html5/#htmldocument interface are limited:
referrer, cookie, lastModified, charset, characterSet.
It would be very useful if a script could get *all* of the response headers,
the raw entity body, and the HTTP status: basically it would be great if the
HTMLDocument interface implemented a subset of of the XMLHttpRequest spec,
namely the parts which have to do with the response (e.g.
getAllResponseHeaders(), getResponseHeader(), status, and others which
appear below). The HTMLDocument interface already has a readyState property
which XMLHttpRequest also has, but the HTMLDocument interface lacks XHR's
onreadystatechange attribute.
If this subset were implemented on HTMLDocument, then scripts would be able
to determine if the page if a 404 or get any other arbitrary information
that is passed in the response header.
Here's a proposed extension to the HTMLDocument interface with some comments
to explain the semantics:
interface HTMLDocument {
...
//another way to get DOMContentLoaded event; the readyState would start
out as LOADING
attribute EventListener onreadystatechange;
// state
const unsigned short UNSENT = 0;
const unsigned short OPENED = 1;
const unsigned short HEADERS_RECEIVED = 2;
const unsigned short LOADING = 3;
const unsigned short DONE = 4;
readonly attribute unsigned short readyState; //already in HTML 5
// request
void abort(); //complements window.stop(): stops the contained document
instead of the associated resources
// response
DOMString getAllResponseHeaders();
DOMString getResponseHeader(in DOMString header);
readonly attribute DOMString responseText; //the non-parsed content of the
document
readonly attribute Document responseXML;
readonly attribute unsigned short status;
readonly attribute DOMString statusText;
}
Re: [whatwg] Implement XMLHttpRequest interface subset onHTMLDocument
Providing the original document tree before transformation in HTMLDocument.responseXML makes sense. In that case, the Document returned should be immutable, just as a DOMString is; I am not sure how to declare it in IDL. Chris _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Weston Ruter Sent: Wednesday, October 29, 2008 8:35 PM To: Kristof Zelechovski Cc: [EMAIL PROTECTED]; Ian Hickson; Anne van Kesteren Subject: Re: [whatwg] Implement XMLHttpRequest interface subset onHTMLDocument This is not completely strange or unexpected construct, since window == window.self. Furthermore, having a HTMLDocument.responseXML would be useful in the case that an XSLT stylesheet outputs HTML, plain text, or something else; in such a case, it would be very useful to get the original responseXML. Note that I don't envision this responseXML being any sort of shadow DOM; I mean, if XSLT did transform the XML data, making a change to responseXML would not cause the XSLT engine to re-parse the updated responseXML. Maybe this would be useful, but it seems overly complicated. On Wed, Oct 29, 2008 at 12:26 PM, Kristof Zelechovski [EMAIL PROTECTED] wrote: The meaning of HTMLDocument.responseXML looks a bit strange and unexpected: a property of an object bound to the object itself by definition. I would suggest leaving that one out. Chris _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Weston Ruter Sent: Wednesday, October 29, 2008 8:19 PM To: Kristof Zelechovski Cc: [EMAIL PROTECTED]; Ian Hickson; Anne van Kesteren Subject: Re: [whatwg] Implement XMLHttpRequest interface subset onHTMLDocument If the interface were implemented as-is, document.responseXML would just be a reference back to the document object. So if the document is XML, then document === document.responseXML On Wed, Oct 29, 2008 at 12:14 PM, Kristof Zelechovski [EMAIL PROTECTED] wrote: What should the property HTMLDocument.responseXML represent? Chris
