What I'm demonstrating
- E-books can work offline - important for flights, holidays, trains etc
- No server trickery needed - both publications and reader can be hosted statically
- It's just the web - publications are just html, so can use css, images, video, audio, svg… anything the web can use. However, script is blocked in the e-book reader, as running arbitrary script would be risky.
- Links - Linking & navigation works as expected, even within imported e-books provided two users have added the same e-book to the reader. Bookmarks can be used as, well, bookmarks. Fancy that.
- Archive obfuscation - The archive has an empty byte added to the start so it can't be read in a regular unarchiver. I don't personally care for this, but if this is what publishers want, it is possible. I guess it worked for WOFF.
What I'm not demonstrating
- UI design - I mean… I just can't.
- Best-practice maintainable code - I hacked it together on a plane for fun.
How service workers are used
- Request interception and caching - makes the whole thing work offline and produces urls and normal navigation patterns in the e-book reader.
- Archive building on the fly - once streams land, the archive format can be generated and read in a more memory efficient way. Although the archive could be generated by a build system, the client side build allows dynamic building of the archive based on user options.
They're just web pages, but with the following requirements:
- Relative URLs - so they can be opened anywhere.
- A manifest file - with the name of the book and the urls it requires.