[whatwg] Implement XMLHttpRequest interface subset onHTMLDocument

I have an amendment to my proposal. There was a
post<http://ajaxian.com/archives/language-jsonp-service>on 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 <giecrilj at stegny.2a.pl
> 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:* westonruter at gmail.com [mailto:westonruter at gmail.com] *On Behalf Of
> *Weston Ruter
> *Sent:* Wednesday, October 29, 2008 8:35 PM
> *To:* Kristof Zelechovski
> *Cc:* whatwg at whatwg.org; 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 <
> giecrilj at stegny.2a.pl> 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:* whatwg-bounces at lists.whatwg.org [mailto:
> whatwg-bounces at lists.whatwg.org] *On Behalf Of *Weston Ruter
> *Sent:* Wednesday, October 29, 2008 8:19 PM
> *To:* Kristof Zelechovski
> *Cc:* whatwg at whatwg.org; 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 <
> giecrilj at stegny.2a.pl> wrote:
>
> What should the property "HTMLDocument.responseXML" represent?
>
> Chris
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081030/0e069f43/attachment.htm>

Received on Thursday, 30 October 2008 00:21:10 UTC