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

Re: document.load: History and a proposal

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 12 Aug 2010 08:33:35 +0000 (UTC)
To: Jonas Sicking <jonas@sicking.cc>, Maciej Stachowiak <mjs@apple.com>, Adam Barth <w3c@adambarth.com>
cc: HTML WG <public-html@w3.org>
Message-ID: <Pine.LNX.4.64.1008120827320.32418@ps20323.dreamhostps.com>
On Tue, 27 Jul 2010, Jonas Sicking wrote:
> On Mon, Jul 26, 2010 at 10:36 PM, Ian Hickson <ian@hixie.ch> wrote:
> > 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.
> Does webkit not support synchronous document.load already? If not, I'd 
> be happy to attempt to remove it from firefox and see what shakes out.
> I'd also love to remove document.load entirely, but I'm less confident 
> that is doable. Does anyone have data? At the very least I'd like to 
> restrict document.load to not work on displayed documents, i.e. 
> documents with a defaultView != null.

On Tue, 27 Jul 2010, Maciej Stachowiak wrote:
> We could try implementing only async and see what happens. Or Gecko 
> could try removing sync support.
> Regarding the "displayed document" issue, we could make only documents 
> created by DOMImplementation.createDocument have the load support, which 
> should effectively establish that limit. There again, I think the compat 
> impact is unknown.

On Tue, 27 Jul 2010, Adam Barth wrote:
> I'm happy to start with the async version.  I don't think we should rush 
> into the synchronous version of the API.  If Gecko removes support for 
> the synchronous API at the same time, that's more likely to cause us to 
> arrive at the happy outcome of not having a synchronous API.
> The cases that I investigated used DOMImplementation.createDocument to 
> create the document on which they called load.

I've limited the API to XML Documents created with createDocument only, 
and removed the "async" attribute so it's always async.

I can also keep the async attribute but make it be ignored, or keep it and 
force it to true (either ignoring setting attempts or making it readonly), 
if necessary for compat.

Let me know if any of this needs changing further. I only commented out 
the sync stuff so it's trivial to put back if need be.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 12 August 2010 08:34:04 UTC

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