[whatwg] Appcache feedback

[Michael Nordman]

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>