Re: [w3c/manifest] Add offline_url option (#774)

I like the motivation for this (increase the number of sites that have a proper "you're offline" error), but I also share @reillyeon 's reticence about adding yet another offline caching mechanism (c.f.: appcache).

The additional concern is that this would essentially encourage devs to go just this far and no further.

We _do_ want to encourage developers to build proper offline support (and poor-network support) into their apps, but we view it as a spectrum, roughly as follows from worst to best:

1. No offline support (generic browser offline error message).
2. Show an offline error page when offline, otherwise serve content from the network.
3. Show the app's normal UI when offline, but rely on the network to do all tasks (i.e., the UI is basically empty when not connected to the internet, still letting you navigate around the app but lots of widgets say "Not available while offline").
4. Perform read caching so that stale content is available for viewing in the app, but the user can't really take any actions.
5. Perform write caching so that the user can do certain actions like compose posts, which are saved in local storage and synced to the server when a connection is found.

Right now, a lot of apps are at 1. We want to push developers as far along this spectrum as possible, because we think the further you are along, the better the experience for the user. (This isn't just about offline either; the further along in this spectrum, the better your app will work in poor network conditions as well, because the user will be able to interact with the pages of the app while the network is dropping in and out.)

While 2 is an improvement over 1, it isn't really _that_ much better. To go beyond 2, you need to implement a service worker and architect your app properly. This proposal basically gives developers an "easy" way to get to 2, but it doesn't at all help with going beyond 2. My concern is that if we give developers an easy way to get to 2, the leap from 2 to 3 is even larger because you haven't gotten even a basic service worker running to get to "good enough". So this may result in more apps settling at 2.

Ideally, we wouldn't be telling developers "start off by making your app show an offline error, and maybe improve it later." We would be telling them to architect their apps so they work as well offline and in poor network conditions as they possibly can.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/manifest/issues/774#issuecomment-515257608