- From: Glenn Maynard <glenn@zewt.org>
- Date: Wed, 24 Apr 2013 07:57:32 -0500
- To: "Robert O'Callahan" <robert@ocallahan.org>
- Cc: WHATWG <whatwg@whatwg.org>
On Wed, Apr 24, 2013 at 6:51 AM, Robert O'Callahan <robert@ocallahan.org>wrote: > Proposal: > Give Web applications APIs to explicitly delay the document load event. In > particular, add a method "document.delayLoadEvent()" that causes the > document load event to be delayed until a corresponding > "document.stopDelayingLoadEvent()" method is called. Allow these to nest so > that the document load event is delayed until at least as many calls to > stopDelayingLoadEvent() have been made as there were calls to > delayLoadEvent(). > 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. (Failing to call finished() would probably have to result in the delay being permanent, as if you missed a call to stopDelayingLoadEvent, so it doesn't expose GC behavior. I suppose that relying on GC here isn't as bad as it usually is, if the effects of this are never exposed to script, but it's still not great since it would require that GC always happen in finite time.) 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... -- Glenn Maynard
Received on Wednesday, 24 April 2013 12:57:57 UTC