W3C home > Mailing lists > Public > whatwg@whatwg.org > December 2009

[whatwg] Appcache feedback

From: Michael Nordman <michaeln@google.com>
Date: Thu, 17 Dec 2009 14:24:07 -0800
Message-ID: <fa2eab050912171424o2eed29a3x3652b276c59e97c4@mail.gmail.com>
On Thu, Dec 17, 2009 at 2:17 PM, Joseph Pecoraro <joepeck02 at gmail.com>wrote:

> On Dec 17, 2009, at 4: 44PM, Ian Hickson wrote:
> Another conforming sequence of events would be:
> 1. The parser's first parsing task begins.
> 2. As soon as the manifest="" attribute is parsed, the application cache
> download process begins. It queues a task to dispatch the 'checking'
> event.
> 3. The parser's first parsing task ends.
> 4. The event loop spins, and runs the next task, which is the 'checking'
> event. No scripts have yet run, so no handlers are registered. Nothing
> happens.
> 5. The parser's second parsing task begins. It will parse the script, etc.
> [snip moved below..]
> We could delay the application cache download process so that it doesn't
> start until after the 'load' event has fired. Does anyone have an opinion
> on this?
I don't think we'd have to delay the update job, just the delivery of any
events associated with the appcache until 'load' has happened to get the
desired effect.

> From an application developer standpoint I think that would be very nice. I
> cannot comment on a this from an implementors perspective (yet).
> It seems important considering the following text from the Spec:
> http://www.whatwg.org/specs/web-apps/current-work/multipage/offline.html#downloading-or-updating-an-application-cache
> [[
> 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.
> ]]
> 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.
> You can work around all this by checking the .status attribute when you
> first hook up the event listeners.
> 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.
> Thanks for the quick response,
> - Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091217/817b774c/attachment.htm>
Received on Thursday, 17 December 2009 14:24:07 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:19 UTC