[whatwg] API to delay the document load event

[Tab Atkins Jr.]

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