Re: document.load: History and a proposal

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

Adam

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