Re: [whatwg] API to delay the document load event (continued)
On Mon, May 6, 2013 at 2:17 PM, David Bruant bruan...@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 either. 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. James
Re: [whatwg] API to delay the document load event (continued)
On Tue, May 7, 2013 at 3:12 PM, Bjoern Hoehrmann derhoe...@gmx.net wrote: * James Burke wrote: 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: I think it would be helpful if you could phrase these in terms of what various implementations should do. For instance, Google shows screen- shots in search results. How should their take a snapshot bot work? I maintain IECapt and CutyCapt; how should they be changed to support the feature being proposed here? Same question for the Firefox and Firefox- OS features that motivate creating a new feature here. If this feature uses the load' event, as long as those tools listen to load, that is enough: when they receive that event, the page should be rendered in the state the web site developer wanted. If a use case is identified that makes it difficult to use the existing load event, then the tools would need to listen to a new event. They would also need to inspect the document state (maybe by checking for a loading attribute on the documentElement?) to know if this new event is in play. Similarily, it would be helpful to approach the problem from the per- spective of content creators. Let's say you have a website, and any new visitor gets to see an overlay that encourages them to sign up with Acme. When would this site signal that it is ready for the purposes I've mentioned? And would all of the implementations cited above wait for this signal? If the load event approach was used, the web site would: * call document.delayLoadEvent() during JS execution (needs to happen before the browser would normally trigger the load event). * Once the Acme overlay DOM element was inserted, call document.stopDelayingLoadEvent() * The platform waits for any images/resources for the current DOM to finish loading. It then fires the normal document load event. For tools that are listening: * Just listen for the load event for the document. --- If a separate event/trigger instead of load is used, then I am not exactly sure what is needed. One guess: For the web site: * stamp the DOM in some way to indicate this new event would be fired, perhaps add the loading attribute to the documentElement. * insert the Acme overlay DOM element, then remove the attribute. * The platform waits for any images/resources for the current DOM to finish loading (?) then fire appload event? For tools that are listening: * Inspect the state of the page, looking to see if there is a loading attribute in play. Listen for both load and appload, and if the loading attribute was detected, wait for the appload event. In fact, the tool needs to discount load if the page detects appload is in play as it may fire. (So, in response to one of David's comments, trying to fallback to load would not be feasible/detectable). James
Re: [whatwg] API to delay the document load event (continued)
* James Burke wrote: 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: I think it would be helpful if you could phrase these in terms of what various implementations should do. For instance, Google shows screen- shots in search results. How should their take a snapshot bot work? I maintain IECapt and CutyCapt; how should they be changed to support the feature being proposed here? Same question for the Firefox and Firefox- OS features that motivate creating a new feature here. Similarily, it would be helpful to approach the problem from the per- spective of content creators. Let's say you have a website, and any new visitor gets to see an overlay that encourages them to sign up with Acme. When would this site signal that it is ready for the purposes I've mentioned? And would all of the implementations cited above wait for this signal? -- Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de 25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/
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
