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

Re: document.load: History and a proposal

From: Adam Barth <w3c@adambarth.com>
Date: Tue, 27 Jul 2010 20:49:51 +0200
Message-ID: <AANLkTinGPS27sc4sPk1sMiLKEcbc13W4SjxEJ+WSxm1V@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.com>
Cc: Jonas Sicking <jonas@sicking.cc>, Ian Hickson <ian@hixie.ch>, HTML WG <public-html@w3.org>
On Tue, Jul 27, 2010 at 8:35 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> On Jul 27, 2010, at 8:51 AM, Adam Barth wrote:
>> On Tue, Jul 27, 2010 at 5:47 PM, Jonas Sicking <jonas@sicking.cc> 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.
>> WebKit doesn't have document.load at all.  This is one of WebKit's
>> biggest compat problems.  I don't know whether the compat issues are
>> coming from the sync or async versions.
> We could try implementing only async and see what happens. Or Gecko could try removing sync support.

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

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

The cases that I investigated used DOMImplementation.createDocument to
create the document on which they called load.

Received on Tuesday, 27 July 2010 18:50:48 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:25:49 UTC