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 21:13:42 +0200
Message-ID: <AANLkTikw9X1+FoneoCF0NGWbqFaRMYQjMYNQnc7qz6+6@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Maciej Stachowiak <mjs@apple.com>, Ian Hickson <ian@hixie.ch>, HTML WG <public-html@w3.org>
On Tue, Jul 27, 2010 at 9:03 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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... ;-)

Ok, twist my arm.  :)

Received on Tuesday, 27 July 2010 19:14:35 UTC

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