W3C home > Mailing lists > Public > public-html@w3.org > July 2010

Re: document.load: History and a proposal

From: Ian Hickson <ian@hixie.ch>
Date: Tue, 27 Jul 2010 05:36:24 +0000 (UTC)
To: HTML WG <public-html@w3.org>
Message-ID: <Pine.LNX.4.64.1007270155130.7470@ps20323.dreamhostps.com>
On Fri, 26 Mar 2010, Adam Barth wrote:
> 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.
> 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
> 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 made an XMLDocumentLoader interface that has "async" (boolean 
attribute) and "load" (method with string argument, returns boolean) 
members and which is implemented only by Document objects that are "XML 
documents" as defined by the HTML specification.

> 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").

It's not clear to me how the pages you mention use XMLDocument as a 
constructor. Could you elaborate?

I have no idea how to specify this requirement. Could you suggest suitable 
spec-ready text?

On Sat, 27 Mar 2010, Michael A. Puls II wrote:
> What do you want to happen with load("file not found")? Do you want 
> load() to throw an exception like Firefox, or do you want it to not 
> throw an exception, still fire the 'load' event and just have 
> event.target.documentElement be null like Opera?

I've made the sync version of load() return true on success and false on 
failure, and have made the document be empty on failure.

> What do you want to happen when load("file is found") is an xml file 
> with a parse error? In the 'load' callback, do you want just 
> event.target.documentElement to be null, or do you want documentElement 
> to be a 'parsererror' element in the 
> "http://www.mozilla.org/newlayout/xml/parsererror.xml" namespace like 
> Firefox does (basically a yellow screen of death document). How do other 
> vendors feel about using that ns string?

I've gone with the document being empty, as if it was a 404.

On Sat, 27 Mar 2010, Michael A. Puls II wrote:
> Should 'load' still fire if doc.async = false? It does in Firefox, but 
> not Opera.

I have made it always fire.

On Sat, 27 Mar 2010, Maciej Stachowiak wrote:
> 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.

I haven't avoided the sync API here, but I'd be glad to remove it if 
browser vendors are not going to support it / are going to remove support. 
As written, the spec can have the sync aspects easily removed.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Tuesday, 27 July 2010 05:36:55 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:21 UTC