[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
>
>
>  ------------------------------
>
> *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:06 PM
> *To:* whatwg at whatwg.org
> *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
> interface <http://www.w3.org/html/wg/html5/#htmldocument> 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;
> }
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081029/a86d7cb8/attachment.htm>

Received on Wednesday, 29 October 2008 12:34:30 UTC