[whatwg] API to delay the document load event
Tab Atkins Jr.
jackalmage at gmail.com
Thu Apr 25 17:23:48 PDT 2013
On Thu, Apr 25, 2013 at 5:15 PM, Bjoern Hoehrmann <derhoermi at 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
>>delay = document.delayCompletion();
>>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.)
More information about the whatwg