W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2013

Re: [whatwg] API to delay the document load event

From: David Bruant <bruant.d@gmail.com>
Date: Sun, 28 Apr 2013 19:28:57 +0200
Message-ID: <517D5C59.2020501@gmail.com>
To: robert@ocallahan.org
Cc: WHATWG <whatwg@whatwg.org>
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
Received on Sunday, 28 April 2013 17:29:26 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:57 UTC