18279 2012-07-18 17:56:26 +0000 Specification should be clearer about when the downloading of the application cache starts. "These events are delayed until after the load event has fired." is a bit misleading. The chrome developer team interprets it as: Start downloading all resources f 2015-06-17 04:53:47 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified Other other RESOLVED FIXED http://www.whatwg.org/specs/web-apps/current-work/#downloading-or-updating-an-application-cache appcache P2 editorial --- 1 contributor robin mike myfacebook plh public-html-admin public-html-wg-issue-tracking robin travil public-html-bugzilla oldest_to_newest 71024 0 contributor 2012-07-18 17:56:26 +0000 This was was cloned from bug 17688 as part of operation convergence. Originally filed: 2012-07-04 08:39:00 +0000 ================================================================================ #0 contributor@whatwg.org 2012-07-04 08:39:43 +0000 -------------------------------------------------------------------------------- Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html Multipage: http://www.whatwg.org/C#downloading-or-updating-an-application-cache Complete: http://www.whatwg.org/c#downloading-or-updating-an-application-cache Comment: Specification should be clearer about when the downloading of the application cache starts. "These events are delayed until after the load event has fired." is a bit misleading. The chrome developer team interprets it as: Start downloading all resources from the manifest file as soon as the page loads, but just delay the events until onload event has been fired. The Firefox team is actually delaying the download of all resources from the manifest file until the onload event has been fired. Outcome in Chrome: Delay between ondownloading and oncache event is minimal(in my testcase 34ms) and in firefox the actual time it took to download all resources. Chromes approach makes these events basically useless, because they are almost at the same time and appcaching is not cancelable. With a better specification, this issue could be solved. Posted from: 90.146.74.58 by simon.schatka@compuware.com User agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.47 Safari/536.11 ================================================================================ 81701 1 robin 2013-01-21 15:58:56 +0000 Mass move to "HTML WG" 81819 2 robin 2013-01-21 16:01:41 +0000 Mass move to "HTML WG" 93460 3 travil 2013-09-16 22:14:35 +0000 I don't believe this is blocking CR (since future app-cache investment will be in the WebApps WG as agreed upon in the April2013 F2F meetings 121167 4 mike 2015-06-17 04:53:47 +0000 See https://www.w3.org/Bugs/Public/show_bug.cgi?id=17688#c7 A change for this is already in W3C HTML nightly/ED