And why can this facts help caching offline webapps? Service workers have access to different browser apis and can listen to events. This allows the workers to intercept and handle network requests. So it is possible to react on requests, cache or modify them for the application needs. And this independent and transparent from the applications code.
Currently, there are different ways of caching offline data: App Cache, WebSQL, Local Storage, IndexedDB. The App Cache can store requests, but has a many gotchas. WebSQL and Local Storage are not really good storage solutions for huge application data. The data has to be fetched, converted and saved manually by the application. Add some new data is the same problem, we can store it in the storages, but we have to convert it back and send it to the server if we are online again.
With web workers it would be possible to receive and send normal requests. And the worker can cache them and response with the cached data if we are offline. In opposite to App Cache we can handle each request individually and additionally we are able to modify them or response with other data. The advantage is, the request has not to be converted and the application does not know about the caching. With the BackgroundSync api it would be possible to sync all of the data in background when a connection is available again.
But why would and could? This sounds like it wouldn't work. And still it is not working cause no browser has all features fully implemented. But the worker and cache api can be tried in the current Chrome and Opera browser. The BackgroundSync spec is currently only an idea on not really a draft. But it is good to know what are new possibilities in -hopefully near- future.