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

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

From: James Burke <jrburke@gmail.com>
Date: Wed, 8 May 2013 19:25:54 -0700
Message-ID: <CAHgY_idPJ2b4pR1qCwuoo4A5GYSzMsXUy-WzfabuZ0PCOV=Jpw@mail.gmail.com>
To: David Bruant <bruant.d@gmail.com>
Cc: whatwg@lists.whatwg.org
On Mon, May 6, 2013 at 2:17 PM, David Bruant <bruant.d@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.

Received on Thursday, 9 May 2013 02:26:18 UTC

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