The harder part seems to be communicating with the user. If/how to let them know they've gone offline, and what that means for their experience, and if they're allowed to create/update content, what will happen when they reconnect.
For example, the next question for me is what to do with conflicting updates, ie when a user updates a document offline and reconnects, and the document has been updated by a different client while they were offline. Discarding or merging isn't a problem from a technical stand point, the problem is presenting it to the user, and striking a balance between doing what the user wants/expects, and not bothering the user with a ton of questions about which of their changes they want to keep/merge.
The problem with this method is ideally you'd like the client to know it's reconnected as soon as possible, and start working through the queue. I figured the most foolproof way was just periodically trying to talk to the server when you think you're offline. It'd probably be better if you had a solid method of receiving actual network related events like disconnecting and reconnecting, but the lazy 'just keep checking' method is workable.
The bonus of it is it works the same if it's a problem on the servers end.