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.
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
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:
Now, I don’t mind much having my name misspelt, it happens so often that I’ve long since ceased worrying about it.
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.
Now, you may not see how this contradicts the previous quote, but it does.
- Don’t support the widget natively.
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.)
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:
- solve a specific problem
- start as simple as possible
- solve simpler problems first
- make evolutionary improvements
- design for humans first, machines second
- be presentable and parsable
- visible data is much better for humans than invisible metadata (see: Principles of visibility and human friendliness).
- adapt to current behaviors and usage patterns, e.g. (X)HTML, blogging
- ease of authoring is important
- reuse building blocks from widely adopted standards:
- semantic, meaningful (X)HTML, i.e. POSH. See SemanticXHTMLDesignPrinciples for more details.
- existing microformats
- as a whole, e.g. use hCard for representing people
- in part, reusing particular semantic class names, following microformats naming principles
- well established schemas from interoperable RFCs
- modularity / embeddability
- design to be reused and embedded inside existing formats and microformats
- enable and encourage decentralized and distributed development, content, services
- explicitly encourage the original “spirit of the Web”
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.
(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.