[whatwg] API to delay the document load event
bruant.d at gmail.com
Sun Apr 28 10:28:57 PDT 2013
Le 24/04/2013 13:51, Robert O'Callahan a écrit :
> Context: https://bugzilla.mozilla.org/show_bug.cgi?id=863499
> 1) User-agents provide thumbnails of Web pages (e.g. desktop Firefox,
> FirefoxOS and Safari do this). We want to avoid taking a thumbnail while
> the application is incompletely loaded. The firing of the document load
> event is not currently a reliable indicator since the application might
> have ongoing load activities (e.g. IndexedDB transactions, Websocket
> activity) that do not block the document load event.
Tools built on top of headless browser tools struggle with this kind of
problem too. The user agent "load" event is most of the time meaningless
at the application abstraction level.
Crawlers/search engines might be interested too as sometimes links in
documents are added dynamically.
> 2) User-agent has UI to distinguish pages that are in the process of
> loading from pages that are fully loaded. As in use-case #1, relying on the
> document load event as currently defined to transition the UI to the "fully
> loaded" state may be inaccurate.
> 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
Both of use cases suggest that the definition of an application being
"loaded" or "ready" is different from the user agent definition, so I
believe delaying the UA load event is a wrong approach as it will lead
Also, I don't see how nested calls to delayLoadEvent help any of your 2
* Have a declarative way for an application to say "I'll tell you when
* A event dispatched by the application to tell when it is ready
Something along the lines of (better names and better details are welcome):
// do a lot of things
This way, any tool waiting for the application to be ready can use the
following algorithm (JS-like pseudo-code):
// after <head> is parsed:
// waiting for load, like today
Having a different independent event will also be the occasion to have a
measure in PerformanceTiming  that is different than load. I believe
having both is useful for different purposes (comparing "load" and
"AppReady" across different user agents, etc.)
This also allows the 'AppReady' event to occur before the UA "load"
which can make sense in some circumstances (below the fold images are
still loading, but the app can already consider itself ready)
What do you think?
More information about the whatwg