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

Re: document.load: History and a proposal

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 27 Jul 2010 12:03:36 -0700
Message-ID: <AANLkTikCUrqvj61WcOu0nF=TACGd4sHke6fUhuckDNUK@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: Maciej Stachowiak <mjs@apple.com>, Ian Hickson <ian@hixie.ch>, HTML WG <public-html@w3.org>
On Tue, Jul 27, 2010 at 11:49 AM, Adam Barth <w3c@adambarth.com> wrote:
> 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
> API.

We could try to remove support and see what happens. Unfortunately I
have too much on my plate so I can't give any promises for Firefox 4.

However if someone were to step up and write a patch... ;-)

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

I believe this is the case everywhere I've seen this used too.

/ Jonas
Received on Tuesday, 27 July 2010 19:04:34 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:19 UTC