<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Dec 17, 2009, at 4: 44PM, Ian Hickson wrote:</div><blockquote type="cite"><div>Another conforming sequence of events would be:<br><br>1. The parser's first parsing task begins.<br>2. As soon as the manifest="" attribute is parsed, the application cache <br>download process begins. It queues a task to dispatch the 'checking' <br>event.<br>3. The parser's first parsing task ends.<br>4. The event loop spins, and runs the next task, which is the 'checking' <br>event. No scripts have yet run, so no handlers are registered. Nothing <br>happens.<br>5. The parser's second parsing task begins. It will parse the script, etc.<br><br></div></blockquote><blockquote type="cite">[snip moved below..]</blockquote><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>We could delay the application cache download process so that it doesn't <br>start until after the 'load' event has fired. Does anyone have an opinion <br>on this?</div></blockquote></div><br><div>From an application developer standpoint I think that would be very nice. I cannot comment on a this from an implementors perspective (yet).</div><div><br></div><div>It seems important considering the following text from the Spec:</div><div><a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#downloading-or-updating-an-application-cache">http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#downloading-or-updating-an-application-cache</a></div><div><br></div><div>[[</div><div>Certain events fired during the application cache download process allow the script to override the display of such an interface. The goal of this is to allow Web applications to provide more seamless update mechanisms, hiding from the user the mechanics of the application cache mechanism. User agents may display user interfaces independent of this, but are encouraged to not show prominent update progress notifications for applications that cancel the relevant events.</div><div>]]</div><div><br></div><div>It seems pointless to provide hooks in the API that allow for a "custom interface", when fundamentally they may never be triggered in an otherwise compliant user agent.</div><div><br></div><div><br></div><div><blockquote type="cite"><div>You can work around all this by checking the .status attribute when you <br>first hook up the event listeners.</div></blockquote><br></div><div>This is even worse. To me, this means the application developer cannot rely on certain (any?) events, so he/she would need to build a completely new API on top? Developers will still likely be caught searching for bugs in their own code (like I did) wondering why behavior is different between browsers.</div><div><br></div><div><br></div><div>Thanks for the quick response,</div><div>- Joe</div></body></html>