Le 24/04/2013 13:51, Robert O'Callahan a écrit :
Context: https://bugzilla.mozilla.org/show_bug.cgi?id=863499
Use-cases:
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.
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().
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
in confusion.
Also, I don't see how nested calls to delayLoadEvent help any of your 2
use cases.
Proposal:
* Have a declarative way for an application to say "I'll tell you when
I'm ready"
* A event dispatched by the application to tell when it is ready
Something along the lines of (better names and better details are welcome):
<html>
<head>
<meta name="customApplicationReadyEvent">
<script>
// do a lot of things
document.dispatchEvent(
document.createEvent('AppReady', appReadydata)
);
//
</script>
</head>
</html>
This way, any tool waiting for the application to be ready can use the
following algorithm (JS-like pseudo-code):
// after <head> is parsed:
if(document.applicationWillTellMeWhenReady){
document.addEventListener('AppReady', takeScreenshot)
}
else{
// waiting for load, like today
document.addEventListener('load', takeScreenshot)
}
Having a different independent event will also be the occasion to have a
measure in PerformanceTiming [1] 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?
David
[1]
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#performancetiming
