document.load: History and a proposal

== 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

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 00:48:39 UTC