- From: Jake Archibald <jaffathecake@gmail.com>
- Date: Sat, 8 Sep 2012 15:36:01 +0100
- To: Chris Wilson <cwilso@google.com>
- Cc: Patrick Gillespie <patorjk@gmail.com>, Andrew Betts <andrew.betts@ft.com>, public-fixing-appcache@w3.org
On 6 September 2012 22:44, Chris Wilson <cwilso@google.com> wrote: > 1) "this app will work offline" is kind of a spectrum, not a Boolean; > obviously, many features of an app may be shut off when disconnected. It's > challenging to capture that well in a UI. This is certainly the case with Lanyrd. Although a simple visit to the site will result in an appcache, the user is in control of which event pages are available offline through tracking/attending. Obviously this behaviour is too specific to include in a spec. We have a little banner that shows a progress meter while caching, and turns into a little notificication when done. http://farm9.staticflickr.com/8320/7955542864_9bea684c83_o.png > 2) However, at a base level, you can leave it up to the developer - the > manifest for Chrome Hosted Apps (web applications on a regular web server, > but with a manifest to be published in the Chrome Web Store) has a special > bit to state that the app is "offline enabled". This lets us highlight apps > that will still work when you're offline (when Chrome goes offline, the New > Tab page grays out all non-offline enabled apps if you are offline). This seems acceptable & is possible in the current implementation. If a URL is associated with a manifest (either explicitly or FALLBACK), the browser can indicate the resource has some kind of offline functionality. This would be misinformative if appcache was being used as a performance hack, and didn't actually provide an offline experience, but I don't think we should cater for that.
Received on Saturday, 8 September 2012 14:36:28 UTC