- From: Adam Barth <w3c@adambarth.com>
- Date: Fri, 26 Mar 2010 17:47:35 -0700
- To: HTML WG <public-html@w3.org>
- Cc: Maciej Stachowiak <mjs@apple.com>, timeless <timeless@gmail.com>
== 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