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

[James Burke]

I just joined the mailing list, so I apologize for not continuing the
existing thread started here:

http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2013-April/039422.html

Disclaimer: I submitted the Mozilla Bugzilla ticket for some kind of
capability in this area.

Summarizing previous discussion points:

1) Should this be tied to document load or some new event/state?
Concerns about messing up scripts that bind to document load.

Not using document load as the API target means also adding a
mechanism for a script that does want to wait for this new state to
detect if that state is in play. For the paired JS API, it implies
providing something like a document.appReadyState if the new event is
tied to some name like "appload". For the html attribute approach,
detecting the attribute is probably enough.

In my experience as a JS library provider (first with dojo and more
recently with requirejs), JS scripts heavily favor binding to
DOMContentLoaded over document load to do work. DOMContentLoaded is
also what jQuery's ready() uses, which I expect is what most sites
that use jQuery use.

It would be good to do a survey of existing public source to verify
the uses of document load vs. DOMContentLoaded. Anyone know if this
has been done before?

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.

2) Use paired JS API (document.delayLoadEvent and
document.stopDelayingLoadEvent being one example) vs. setting an html
attribute "loading" and removal the attribute trigger the event.

The JS API allows less coordination among multiple scripts. I can see
this becoming more important with Web Components. The HTML attribute
loading solution would likely push that API into library-specific APIs
use cases, which just seems to result in the same outcome, but in ways
that make it harder to use scripts from disparate sources -- the
scripts would need to buy into library-specific APIs.

3) What about errors?

I would expect this to work how errors affect onload notification now.
The behavior/consequences seem to be the same for paired JS API vs.
attribute approach.

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.

----
Summary
----

I am fine with the paired JS API approach tied to document load, as a
web app developer and consumer of the API. I do not have a particular
favored design of what that paired API looks like.

If there is agreement on focusing on a paired JS API and for it being
tied to onload, perhaps the API discussion could begin.
document.delayLoadEvent and document.stopDelayingLoadEvent is one
suggestion, and I am fine with that. Glenn Maynard also suggested a
`new Something` then `somethingInstance.finished()` as the API. That
one implies tracking the instance, so something that could get lost
particularly if attached to an object and incorrect `this` bindings
interfere. But I have no strong opinion on the API matter, and defer
to whatever browser vendors would want to implement.

James