On Thu, Apr 25, 2013 at 12:57 AM, Glenn Maynard <gl...@zewt.org> 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. > To me, defining a new "time of completion" for a page which can be delayed independently of the document load event seems heavy-handed --- adding something new for which there isn't a clear need. 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. > That would be perfectly acceptable, although it seems a little overcomplicated to me. > Rob -- q“qIqfq qyqoquq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qlqoqvqeq qtqhqoqsqeq qwqhqoq qlqoqvqeq qtqhqeqmq.q qAqnqdq qiqfq qyqoquq qdqoq qgqoqoqdq qtqoq qtqhqoqsqeq qwqhqoq qaqrqeq qgqoqoqdq qtqoq qyqoquq,q qwqhqaqtq qcqrqeqdqiqtq qiqsq qtqhqaqtq qtqoq qyqoquq?q qEqvqeqnq qsqiqnqnqeqrqsq qdqoq qtqhqaqtq.q"