W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2013

Re: [whatwg] API to delay the document load event

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 25 Apr 2013 17:23:48 -0700
Message-ID: <CAAWBYDCmuwFgnbJ0YZvYzjnc37TkyAXdONtp2WihNKbEkn+OKQ@mail.gmail.com>
To: Bjoern Hoehrmann <derhoermi@gmx.net>
Cc: WHATWG <whatwg@whatwg.org>, Glenn Maynard <glenn@zewt.org>, Robert O'Callahan <robert@ocallahan.org>
On Thu, Apr 25, 2013 at 5:15 PM, Bjoern Hoehrmann <derhoermi@gmx.net> wrote:
> * Glenn Maynard wrote:
>>This seems a bit heavy-handed.  For these use cases, it doesn't seem like
>>you need to delay the whole onload event, which would have tons of
>>side-effects on the page.  You could just tell the browser that you're
>>still doing things, without it having other script-visible effects.
>>
>>The particular API above makes it easy for calls to be mismatched in subtle
>>ways, which would be hard to debug. I'd recommend doing this with an
>>interface:
>>
>>delay = document.delayCompletion();
>>...
>>delay.finished();
>>
>>That way, you can simply call finished() anywhere your process can finish,
>>without having to worry about calling it too many times.
>
> This seems to be based on the assumption that all relevant code works on
> the `delay` variable, without addressing the case of calling the method
> `delayCompletion(...)` multiple times.

No, Glenn's proposal is that each call to document.delayCompletion()
returns an independent delayer object.  The document only finishes
loading when all delayer objects have finished.

It's a closer analogue to the current behavior, described by roc in
the OP.  Rather than a crazy hack that actually hits the network, this
just generates objects whose sole purpose in life is to delay the
document load until they're finished.

>>Both of these APIs are effectively manual resource collection, though,
>>which makes me nervous.  It's not something the platform is designed for
>>(hence all the difficulty with blob URLs).  Something like
>>document.delayUntil(indexedDbTransaction) would be nicer...
>
> That also does address calling `delayUntil(...)` multiple times. And in
> both cases, if multiple calls to either method have to be matched up,
> you end up with the same problem that those multiple calls are hard to
> match up.

Hm?  In Glenn's original proposal, there's no difficulty with matching
- each delayer is an object, and you just kill it individually.  In
his suggestion for delayUntil(), there's no matching at all - it
automatically completes as soon as something else completes.

(Perhaps this means we need something that can take a Future, and
delays the document load until that future resolves?  For legacy, it
can take other objects like IDBTransaction, and work analogously.)

~TJ
Received on Friday, 26 April 2013 00:24:33 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:57 UTC