EPUB 3.0 and Scripted Content Documents
One of the headline features in EPUB 3 is support for Scripted Content Documents — that is, JavaScript inside an ebook. So you might be surprised that the spec itself could scarcely be more down in the mouth about it:
Authors should use declarative techniques whenever practical to increase the interoperability, longevity, and accessibility of the Publication, and avoid the inclusion of scripting whenever practical.
And the EPUB Overview document introduces it with similar tepidity:
Authors should also note that scripting in an EPUB publication can create security considerations that are different than scripting within a Web browser… Therefore, it is strongly encouraged that scripting be limited to container constrained contexts.
Here we have a curious situation where even the standards body admits to deep reservations — in the spec itself — about the very thing that is garnering headlines and, it hopes, eventual adoption.
It’s worth asking why something so listlessly introduced is in the spec at all.
But actually that’s the third of my questions. Let’s do the other two first. First, is it practicable? Second, what happens if we do this?
Implementing EPUB 3.0 interactivity
There’s surprisingly little in the spec about the implementation requirements for scripting — it’s much less “How this will work” and more “This can work, right?”. The one substantial technical edict in the spec is this chunk:
In [the container-constrained] model of scripting, the script execution is constrained to the scope of a Content Document embedded in a parent Content Document using one of the HTML5 object, iframe or embed elements. An executing script may have read access to the DOM of its parent Content Document, but the Reading System must not allow it to modify that DOM, nor other content in the Publication. The script must not manipulate the size of its containing rectangle.
As far as I know — and I have some practical experience here but by no means know everything — the “container-constrained” model describes a JavaScript security model unlike any previously proposed anywhere. The internals of the container can access the internals of the parent, but read-only, immutable.
How that is policed is not prescribed. Why those are the given thresholds is not explained. It might be repagination concerns. It doesn’t have anything to do with security, since the described model gives enough license to the contained element that it can pluck as much data from the parent as it likes, and send it wherever it wants. For example, an EPUB could contain a script that sends cookie values, like login or session data, to a remote server (leading to questions like “Have you checked the EPUB for trojans?”). The trusted gamut of activity in the spec is far too wide for these restrictions to be considered ‘security’.
In any case, I don’t believe this can be implemented without deep modifications to whichever JavaScript engine you choose to adopt. It’s absolutely not within the capabilities of browser-based ebook readers. (That’s okay, of course — I found myself cringing at every reference to browser-based readers in the spec. I would much rather the spec said Monocle was non-compliant than contorted itself painfully to accomodate this kind of reading system.) The point is that it implies an awful lot of work for any reading system, all to implement a curiously arbitrary set of restrictions.
The Garden Path
Let’s say a few reading systems — including Monocle — allow scripting wholesale, implementing whatever basic security and UI compatibility they can. What happens next?
Well, a few ebook creators will make EPUBs with scripting. If they resemble me at all, they’ll completely disregard the stern warnings in the specs. They’ll test it in iBooks, they might even test it in Booki.sh (Monocle) and, I dunno, Bluefire. After a few iterations, they’ll get it to work more or less perfectly in iBooks, and sorta kinda okay in Monocle and Bluefire. Then they do the obvious calculus, which says that iBooks has the lion’s share of the audience, so they slap a label on it which says “Works best in iBooks.” If it blows a gasket in Monocle because the interaction model is incompatible (iBooks turns from page margins, Monocle from the right 33% of the page), the label might read “Only works in iBooks.”
Well cry me a river, JP. The market is what it is, and certain advantages accrue to the market leader.
I’m fine with that. I’m happy with Apple’s experiments in “fixed layout” illustrated books — these are no part of the EPUB spec, but very much part of the iBookstore. Threepress has done some remarkable things within this informal arrangement.
I don’t think it’s the role of the IDPF to encourage the preconditions that result in only one reading system being targeted by ebook creators. The role of the EPUB Working Group must be to ensure, as far as possible, that any compliant reading system will successfully display the book as intended by the ebook creator. The draft of the EPUB 3.0 specification candidly admits that this is not possible with scripting:
Reading Systems may render Scripted Content Documents in a manner that disables other EPUB capabilities and/or provides a different rendering and User experience, such as, for example, disabling pagination.
With that in mind, let’s get back to the third question.
Why are we doing this again?
I don’t know why scripted interactivity is in the EPUB spec. My guess is that EPUB is haemorrhaging some use cases to “apps”, as publishers seek to differentiate their product in the marketplace. That’s more imagined than real; in almost every case those books that are transforming into successful apps were waiting to be apps (or websites) all along.
I’ve said all this before.
To my mind the best option is to create an unofficial offshoot project, dependent on EPUB but of which the EPUB spec admits no knowledge. This project would take as its charter to explore and perhaps codify interactivity solutions driven by mature implementations. It would be something like what Open Bookmarks is doing for the much more pressing problem of notes and shared bookmarks — an interest group with a goal in mind.
Another option is simply to let implementations run ahead, permitting scripting and making refinements as they see fit. The ebook creator gets no guarantee of continued compatibility, but if they accept that, they can explore the rich fields of interactivity with abandon. This is no worse than the de facto situation with so-called “enhanced EPUBs”, which are categorised as a different format by digital warehouses, aggregators and publishers everywhere.
Both are surely better courses of action than including this half-baked idea in an already overflowing EPUB specification.
For a more detailed discussion of the problems with scripting in EPUB, take a look at my long, good-natured article about EPUB 3.0. It’s from last June, but arguably more pertinent today.
— Joseph Pearson