Le 06/05/2013 21:35, James Burke a écrit :
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.
If the UA load event is delayed, I guess the delayed value is what is
registered in performance.timing [1]. Then, how do people keep track of
their performance for the actual UA load event? I would recommend
separating the "app ready" mechanism from the UA load event.
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.
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.
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.
Light versions of Caja [2][3] would allow each independent components to
both use standard APIs and coordinate easily.
Specifically for Web Component, maybe each component could have a
component-wide setting to tell it's ready. That probably even makes a
lot of sense.
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.
Agreed.
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).
----
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.
I still strongly believe the UA load event should be kept out of this
discussion and a new independent thing should be added instead.
Thanks,
David
[1]
https://dvcs.w3.org/hg/webperf/raw-file/tip/specs/NavigationTiming/Overview.html#performancetiming
[2]
https://groups.google.com/d/msg/google-caja-discuss/tFhYLJ4abL4/1Mq34zXd_z0J
[3]
https://groups.google.com/d/msg/google-caja-discuss/tFhYLJ4abL4/p0xUcsV99boJ
