While the EPUB3 specification includes support of HTML5/CSS/JS as a distributable package file, in practice many readers have poor and/or selective coverage.
Section 2.9 Scripting of the EPUB3 specification advises:
EPUB strives to treat content declaratively — as data that can be manipulated, not programs that must be executed
Notable readers that do not support javascript:
- Google Play Books
- Kindle (converts epubs to KF8 which does not support javascript)
While it's possible to integrate communication to a Learning Record Store (LRS) via javascript in an epub file, it's important to understand the risks involved.
Using an approach of graceful degradation will limit the likelyhood that a book would become unreadable. This finding led to the development of a xapi-html5-data-attributes.
Ideally, supporting communication to an LRS at the client (reader) level is preferred, this is still undergoing investigation.
Without an LRS proxy, the credentials for an LRS user would be included in the epub. Push to move towards oauth, oauth 2, or a proxy to the LRS. The LRS still needs to implement protection against theoretical attacks.
- Apple "requires" a .plist file for metadata read by iBooks, which is outside the specification
- CSS in books can be overridden by a reader
- It is important to maintain accessibility
- Browser based readers provide a more robust engine than most readers (if not all), thus providing a false sense of capabilities the EPUB3 format can support
- This epub validator will give a sense of how well a book validates against the spec
- Check the tools folder (warning, generated books are not production ready)
Moving forward, Markdown has been identified as a possible pipeline for publishing, access to information and consistency... details to come.
README In Progress