Re: document.load: History and a proposal

Thanks for sending this message - you've laid out the information very  
well.

On Mar 26, 2010, at 5:47 PM, Adam Barth wrote:

> == Use Case ==
>
> Some number of web sites use the following pattern to load XML:
>
>    xmlDoc = document.implementation.createDocument("", "", null);
>    xmlDoc.load(url)
>    xmlDoc.onload = function() {
>        // xmlDoc now contains an XML DOM loaded from url
>    }
>
> Relatedly, other web sites use a similar synchronous pattern:
>
>    xmlDoc = document.implementation.createDocument("", "", null);
>    xmlDoc.async = false;
>    xmlDoc.load(url);
>    // xmlDoc now contains an XML DOM loaded from url

I'm much more concerned about the synchronous version of this API. Is  
there a way to tell how many sites use specifically the synchronous  
pattern, and how many depend on the request being fulfilled  
synchronously? It's true that synchronous XHR already allows blocking  
network I/O, but it's a regrettable part of the platform and I'd  
rather not add more constructs along these lines.

This also implies some additional variants on options 2 and 3:

2.a/3.a) Wherever load is offered, ignore the async attribute and make  
it always load asynchronously.
2.b/3.b) Wherever load is offered, if async is set to false, make the  
load always fail.

I wonder what the compatibility impact of these kinds of options would  
be.

>
> The document.load API is implemented by Internet Explorer, Firefox,
> and Opera.  WebKit and Chrome have bugs on file for implementing the
> API:
>
> https://bugs.webkit.org/show_bug.cgi?id=9063
> http://code.google.com/p/chromium/issues/detail?id=988
>
> Here's an arbitrary selection of web sites that (at least sometime in
> the past year) required the API to function properly:
>
> http://cms.cern.ch/iCMS/
> http://globes.co.il/news/article.aspx (all the globes.co.il URLs load
> the same page template)
> http://my.ynet.co.il/weather/new/
> http://www.theweathernetwork.com/weather/CAON0512
> http://illinoishomepage.net/
> http://www.csnradio.com/
> http://www.eveningexpress.co.uk/Default.aspx?UserKey=
> http://www.lsua.edu/
> http://wwwe.way2sms.com/content/index.html
> http://www.yescar.cn/szzc/sziframe.html
> http://www.domapi.com/
> http://www.cheaptickets.com/App/PerformMDLPDealsContent?deal_id=cheap-travel-deals&cnt=PRO
> http://www.guitar-map.com/fr/a/ppm.php?idw=123377
> http://map.sogou.com/
> http://airtel.in/wps/wcm/connect/airtel.in/Airtel.In/Home/ForYou/Broadband+Internet/Tariffs/
> http://www.spotmapsbrasil.com.br/node/1
> http://www.productsandservices.bt.com/consumerProducts/displayTopic.do?topicId=25500
> https://profile.microsoft.com/RegSysProfileCenter/InfoDefault.aspx
> http://www.cbf.com.br/php/home.php?e=0
> http://www.yx007.com/list/play_14591.htm
>
> I've personally been unable to use certain web sites in WebKit because
> WebKit lacks the API.
>
> == History ==
>
> The document.load appears to have been implemented originally in
> Internet Explorer.  Netscape implemented the API in 2000 on all
> documents.  In 2001, Netscape discovered that exposing the load API on
> all documents creates compatibility problems with some seemingly
> innocuous JavaScript:
>
> <script>
> function load(form) { ... }
> </script>
> ... <select onchange="load(this.form)"> ...
>
> See <https://bugzilla.mozilla.org/show_bug.cgi?id=100795>.  The issue
> is that the document object is in the scope chain for inline event
> handlers.  If an inline event handler attempts to call a function
> named "load" in the global scope, the handler will call document.load
> instead, breaking the page.
>
> To work around this issue, Johnny Stenback created the XMLDocument
> interface and caused non-HTML, non-SVG documents to inherit from
> XMLDocument (which, in turn, inherits from Document).  By moving the
> load API (and its associated async flag) to XMLDocument, Johnny was
> able to provide the proper functionality for all the code snippets in
> this email.
>
> == Conflicts with HTML5 ==
>
> HTML5 restructures the inheritance hierarchy of Documents such that
> HTMLDocument no longer inherits from Document (although SVGDocument
> still inherits from Document).  Instead, HTML5 specifics that every
> document (with a lower-case "d") should expose all the API on all
> Document-like interfaces (e.g., Document, HTMLDocument, and
> SVGDocument).
>
> Unfortunately, this approach conflicts with the requirements for
> document.load because we need to expose the load API on documents
> created by createDocument but we cannot expose the API on all document
> objects (in particular, we can't expose it on HTMLDocuments and likely
> not on SVGDocuments either).
>
> == Ways Forward ==
>
> There are a number of alternatives for resolving this issue:
>
> 1) Abandon document.load.  In 2009, timeless proposed deprecating
> document.load (see
> <https://bugzilla.mozilla.org/show_bug.cgi?id=494705>).  We could
> ignore the API and hope the web will eventually stop using it.  I do
> not favor this approach given the number of bugs filed against
> WebKit-based browsers for not implementing the API and my personal
> experience with such web sites.
>
> 2) Specify the Firefox behavior in HTML5 and implement it in WebKit.
> This approach has the benefit of the better part of a decade of
> implementation experience.  I'm highly confident that implementing
> precisely the Firefox behavior in WebKit will improve compatibility
> and interoperability.  Specifying that behavior in HTML5 would then
> align all three (and possibly Opera and IE as well, although I haven't
> studied their implementations in detail).
>
> 3) Instead of altering the inheritance relation between Document-like
> interfaces in HTML5, we could expose the load API just on documents
> created by document.implementation.createDocument.  This would have
> the benefit of fixing the lion's share of the compatibility problem
> while minimally impacting the rest of the web platform and its
> architecture.  We could expose the API either by magically adding the
> method to such documents or by causing such documents to inherit from
> a subinterface of Document that provided the API.
>
> == Proposal ==
>
> I propose we adopt approach (2) because it has the highest assurance
> of being compatible with the web.  However, some members of the WebKit
> community oppose this approach because of the harm it would cause to
> HTML5's unification of the Document-like interfaces.
>
> == Related Issue ==
>
> Relatedly, some number of web site depend on the existence of the
> XMLDocument constructor in the global scope.  WebKit satisfies these
> web sites by pointing window.XMLDocument at the same object as
> window.Document (note the capital "D").  If we adopt (1) or (3), we
> should update HTML5 to expose this property in this way.  If we adopt
> (2), this issue will resolve itself naturally.
>
> Adam

Received on Saturday, 27 March 2010 21:03:51 UTC