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

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

Received on Monday, 6 May 2013 21:17:35 UTC