Baldur Bjarnason

iBooks widgets – to javascript or not to javascript

– Baldur Bjarnason
Opinions are a nuanced thing and not to be caricatured by people with an agenda.

I’ve been pleasantly surprised by the attention my three iBooks posts have recieved1, but one aspect of that attention is something I never expected.

Although, I should have, I guess.

I have been quoted in so many different contexts and to support so many different sides of somebody’s pet argument that I’ve long given up keeping track. Judging by some of the blog posts out there I’m anti-Apple, pro-Apple, pro-standards, anti-standards, pro-javascript, anti-javascript…

By this point I’m almost expecting to be quoted as for or against somebody in a South Wales by-election.

So, I gave up on reading the sites that linked to those posts. It would have been a waste of time. The discussion veered into irrationality from the get go.

I do, however, follow links in my twitter feed and that’s how I came upon this blog post: A favour from Goliath: How Apple does ebook widgets right by Joseph Pearson

There he points out some of the strong points in Apple’s approach to interactive ebooks, namely that no-code widgets are easier for authors to use, generally perform better (reading systems can opt for more efficient implementations than javascript), they are a functional description of intent that reading systems can adapt to their context, and they can be implemented by ePub reading systems that don’t otherwise support javascript.

All good points that I agree with. No-code widgets are a good idea. And not just for ebooks, they might well be a good idea for the web as well. I was nodding along with most of the points he made.

Which made this little paragraph more than a little bit surprising:

So we were surprised and delighted by some aspects of the .ibook file that iBooks Author spits out. Their extensions to EPUB are done precisely the right way. They’re not done with dollops of embedded JavaScript — a fact that Baldur Bjarnasen (sic) laments.

Now, I don’t mind much having my name misspelt, it happens so often that I’ve long since ceased worrying about it.

But, mischaracterising my opinions is a different matter. I don’t lament the fact that the widgets aren’t implemented in javascript. I only lament that Apple didn’t choose to implement their new capabilities in a standards-friendly way on top of ePub3.

For the record, here’s what I said about iBooks widgets:

The solution they chose for widgets is also perplexing since ePub3 provides a solution exactly for this use case: Bindings.

ePub3 provides a standard method for defining handlers for media types it doesn’t support. Through the bindings element Apple could have provided handlers for its widgets, written in javascript, so that its books would have been forward compatible with other, future, ePub3 reading systems.

Now, you may not see how this contradicts the previous quote, but it does.

The bindings element allows for fallbacks, written in javascript, for those systems that don’t support that specific mediaType object natively.

The javascript is only for those reading systems that:

  1. Don’t support the widget natively.
  2. Support javascript.

This isn’t nitpicking. I completely agree with Joseph Pearson on the positive qualities of native, no-code, widgets. I just think that Apple should have done them in such a way that would allow for javascript fallbacks for ePub3 clients that will support it. Javascript is the only cross-platform, standard, way of delivering interactivity at this level and we shouldn’t intentionally exclude the reading systems that choose to implement it.

Another detail he forgets to mention is that iBooks 2.0 supports javascript-based widgets. Apple only implements five widgets entirely natively (the Keynote slideshows are largely HTML/CSS/JS) and heavily promotes the capability to fill your books with widgets coded in javascript when the native ones don’t suffice.

My problem with Apple’s widget implementation is that it’s a bit crap. It suffers from a couple of flaws that limit it and make their long-term use a pain in the arse. (At least, if you hand code. You’ll probably be fine if you just use iBooks Author.)

To wit:

Intentional incompatibilities

Using data-* attributes instead of PARAM tags specifically prevents the use of ePub3’s BINDINGS tag to point at JS implementations of those widgets in those cases when a native implementation is not available. A compliant ePub3 reading system wouldn’t pass the data-* attributes on to the handler document.

Rubbish as a microformat

There are clear principles behind the design of a microformat. From the microformats wiki:

The iBooks 2.0 widget formats are none of these things. They are opaque, unreadable, complex, represent a complete break from current practices, don’t reuse widely adopted standards, so on and so forth. It’s a format that is patently unusable outside of a WYSIWYG application.

Which is fine, but limiting.

I probably should state my opinion on the iBooks 2.0 format once, as simply and cleanly as possible, so that people would stop making shit up and claiming it to be my opinion.

What I think

With the iBooks 2.0 format, Apple has innovated and extended the ePub3 format.

Their innovations and extension are, for the most part, clever and well implemented. There’s not much in it that I disagree with on a technical level.

My issue is that they could have done exactly the same thing, but done them in a standards-friendly manner. Instead, we have a format that is full of intentional incompatibilities with ePub3 – the format they extended – HTML, CSS, and javascript. These incompatibilities are non-trivial, both to implement and to circumvent.

(One such incompatibility is that you can no longer link to stylesheets in the XHTML files using the LINK element. You have to use an xml-stylesheet declaration. There are many many others.)

Moreover, I truly think that Apple would have been better off if they had decided to strengthen the ePub3 platform instead. They wouldn’t have been limited by the ePub3 format in any way. They could have chosen to do exactly the same thing they have done with the iBooks 2.0 format (with the possible exception, possibly, of the CSS layout extension, but tackling that subject would be material for several other blog posts, I think).

They would have gained much more mindshare, both among publishers and readers, and, together with other ePub platforms, would have presented a much more formidable opposition to Amazon’s Kindle platform.

Instead, they chose to implement what I think will be a short-lived niche format.

I don’t see how that makes any sense, not in terms of business, not in terms of finance, not in terms of marketshare.

  1. The iBooks 2.0 textbook format, The iBooks 2.0 built-in widgets, and The pros and cons of the iBooks 2.0 textbook format ↩