[whatwg] API to delay the document load event (continued)

James Burke jrburke at gmail.com
Wed May 8 19:25:54 PDT 2013

On Mon, May 6, 2013 at 2:17 PM, David Bruant <bruant.d at gmail.com> wrote:
> Le 06/05/2013 21:35, James Burke a écrit :
>> Just going on my experience (admittedly a limited data set): anything
>> that actually binds to document load really wants to know when "all
>> resources loaded (images/iframes) and page is considered complete",
>> which fits with the motivations of this new capability.
> An app could be considered complete before the UA load event (hidden iframe
> hasn't finished loading, below-the-fold images haven't fully loaded yet,
> etc.)
> Delaying the load event doesn't take that into account.

That is fine. If they wanted to signal "complete" for those purposes,
they could delay that other work until the load event fires.

>> If the concern is about an async script erroring out between the
>> paired calls/addition and removal of an attribute, then perhaps any
>> uncaught error ends up triggering the same behavior that occurs now
>> when there is an error during onload determination.
> In case a component fails to notice it's ready, having the "app readiness"
> event separated from the UA "load" event would allow outsiders to use the UA
> "load" as fallback (which is the current best approximation).

"load" could "fail" with a long requested image too. I don't see this
as a strong argument for a separate event.

I'm not opposed to a different event, but I also do not feel like
there have been strong cases that point to it being a separate event

By using load, I expect most code that is outside the app would not
need to change, as the observers of this state are likely already
using 'load', and it fits in with the definition of 'load'. It is just
that the platform cannot expect to detect the state on its own now
give async startup approaches and JS-generated HTML.

If there is really a case that falls down by delaying the load event
it would be good to know. That would point strongly to using a
different event.


More information about the whatwg mailing list