[whatwg] Appcache feedback

Michael Nordman michaeln at google.com
Thu Dec 17 14:24:07 PST 2009

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-0002.htm>

More information about the whatwg mailing list