29 February 2012

Javascript in ebooks

There is a way to solve this problem and keeping almost everybody happy.

But first the case against and for javascript in ebooks.


The reasons not to support javascript are quite numerous. When you list them all I’m almost embarrassed about how much of an ebook javascript supporter I’ve been in the past. (I still am, in a way. But more on that later.)

Problems for ereader vendors:

Javascript in ebooks also has problems for authors/devs. Where many ereaders have no update story, ebooks are worse. One of the core concepts in web development is iterative development. Every website is a living thing that is regularly updated and tweaked to match the changing browser landscape. Javascript-heavy websites that aren’t updated often end up being unusable when the market takes an unusual turn. There are many pages, for example, that still don’t work on the iPad, despite it having a screen resolution and CPU speed that was considered desktop mainstream only a few years ago.

Ebooks that rely on javascript are, quite simply, going to stop working some day. Any ereader vendor who wants to support JS in ebooks has to support automatic, silent, background ebook updates so that ebook authors can push out fixes when (not if) the books break.

Apple’s current tactic with iBooks is worse than useless:

In short, iBooks is a nightmare to develop for. It is the platform from hell. It offers more design features than other platforms, and is the only one that supports javascript, but, frankly, those features aren’t worth the pain involved.

So, if iBooks is any indicator of what the authoring experience for ebook javascript will be like, then you can count me out.

Thanks, but no thanks. I put a higher value on my sanity than that.

There’s one additional hurdle. One that most people keep misunderstanding when I state it: Apple won’t let third party ereader apps ship with javascript support.

They think I’m saying that Apple won’t let ereader apps ship with more or better javascript support than iBooks, or that Apple will be heavy-handed in protecting iBooks from competitors.

They may well, but that’s not the reason. Apple wouldn’t let ereader apps ship with comprehensive javascript support even if they didn’t make iBooks and weren’t in the ebookstore business.


Because an ereader app that supports javascript in ebooks is, as I said above, an app platform and Apple doesn’t allow competing app platforms ship through the iOS app store. They just don’t. They even sometimes block apps that vaguely smell like app platforms, like customisable dashboards and the like.

Allowing an app platform to ship via the iOS app store would be a major policy change at Apple.

The only exception I can think of is if an ereader app adds javascript support that is horrible, buggy, and unusable, Apple might let that slide, but that won’t help authors, for obvious reasons.

Third party ereader apps just aren’t going to ship with javascript support on iOS and iOS is too big a chunk of the tablet market to be ignored. Nobody is going to author javascript-enabled ebooks when they’d only work in less than 10% of the market. It doesn’t matter what the ereader vendors keep saying, or what IDPF says, it just isn’t worth it for authors or publishers. A delusion repeated like a chant still remains a delusion.


With all those problems, why have I always been in favour of javascript in ebooks, even to the point of tweet-flooding the patient folks at IDPF about the issue?

Simple: We don’t know what an interactive ebook looks like, yet.

We have plenty of ideas. Quite a few antecedents from the days of pre-web hypertext. Then a few more from the era of CD-ROMs. These interactive works vary enormously and require different capabilities. Then we have the web.

All of these platforms have allowed some sort of programming and many of the common features require it.

We are only now, after two decades, reaching a point where we have a bit of an idea of what common features the web requires and have started to implement them declaratively (like some of HTML5’s form features). Even so, we still rely on javascript because it’s just simpler than going through the process of inventing and then standardising declarative methods of authoring the same features.

We aren’t even close to this for ebooks. We don’t know what we want. We don’t know what we need. We don’t know what will be popular or enjoyable. What we don’t know can’t be implemented as native widgets and can’t be integrated into the ereader’s UI and chrome.

The problem space

There are several contexts were javascript might be useful in an ebook.

Main body. Running a script in the primary text of the ebook gives you access to several things. You can:

Most of these options don’t seem particularly appealing. StretchText never grew beyond a niche and I’m not sure readers are comfortable with the idea of having their book reading tracked like their web reading. Some of these options might be useful but are next to impossible to do well. (Intelligently coming up with useful/interesting changes to main content is harder than it sounds.)

Dynamically adding links might be useful, but since most uses I can think of (and most precedents) are sleazy marketdroid tactics, that’s also of doubtful value.

Still, hard to know the value when nobody’s trying.

Embedded widgets. The web equivalent would be iframes executing javascript code.

The iBooks 2.0 textbook format implements this, at least for native widgets. (I don’t know if they do so for HTML/JS widgets).

The web has plenty of examples, most of them ads. Google, I think, uses this for their native HTML5 video embed codes.

Popups and appendices. This is how a large majority of non-app interactivity works on the web. You take an action (click on an image, link, graphic) and something interactive pops up in an overlay or separate window. Then you use the slideshow, flash infographic, or whatever in that separate window or context and when you’re done you close it to return. The state of the original reading context is preserved.

Spine. A javascript that runes in the context of the entire book – not just a chapter – with access to the entire book’s structure.

Not many antecedents because it hasn’t really been done before. But I can think of several hypertext structures and tactics that would probably require this. Many of the hypertexts that have been authored with Storyspace, for example, might need this. The most complex ones are usually distributed as applications.

The solution

One solution has already been implemented by, at least, a couple of apps:

Kindle and Kobo for iOS (I haven’t tested the Android versions) both do this when you click on a link in an ebook. An embedded webview window pops up fullscreen over the main content. You aren’t thrown out of the app into Safari. You aren’t asked what you want to do before throwing you out of the app into Safari (iBooks really is one on the most half-baked apps I’ve ever encountered). You just get a fully-fledged, fully-enabled, browser view in an overlay over the book.

The best part is that this is standard practice across the iOS platform – most apps pop up a web page in an overlay – so the readers will know exactly what to do and how it works.

It’s easy to see the use cases:

When an OS or browser engine update breaks the web pages, the author just updates them on the server like any other web page. No need to involve the ereader vendor.

Of course, websites don’t live as long as books might, many of them go offline after a few years, but I doubt that would be as big a problem as people expect.

This also is completely useless when the reader is offline, but that’s a small price to pay, IMO.

This solution, obviously, only addresses overlay widgets, but that’s a very big and rich territory for us to mine in authoring ebooks.

Officially supporting this as a way to extend ebooks also gets ereader vendors out of implementing and supporting javascript.

Improving the solution

Ereader vendors can improve on this in several ways.

They can offer integrated mirroring for webpages that are supposed to be linked to from their ebooks. That way they can make sure the pages are live (if the official page is down, load it from a mirror) and don’t go offline for the lifetime of their platform.

They can implement prerendering in their ereaders. The ebook author would include this:

<link rel="prerender" href="http://example.org/index.html">

in a tag in the head of the current ebook chapter and the ereader would prefetch and prerender that page, off-screen, so that it displays instantaneously when the reader presses the link or thumbnail.

They might even extend the ePub’s metadata with a scheme that lets authors list prerendering hints; a list of webpages they intend to link to from the book. The ereader could cache the files and when a chapter is loaded that links to one of these files it could prerender the page while the user is reading the main text. They could even use this metadata list to implement backup mirrors for the web pages.

If you can’t tell, I like this solution

I think this is a classic 80/20 compromise. It gets us 80% of what we want from both widgets and javascript with 20% of the effort.

With prerendering and official mirroring we get what we want, both as readers and authors. We get stability. We get rich interactivity. We get javascript.

All with much less hassle for the ereader vendor than full javascript or widget support would entail.

Best of all, we already have a basic implementation of this solution on two major platforms, Kindle iOS and Kobo iOS.

Everything on this site is written by . In case you hadn't guessed already.