Some of what follows may be less than fully informed, because I’m only a casual observer, endeavouring to make a system that is EPUB-friendly if not EPUB-compliant. But it seems to me there are two key problems with the way the EPUB spec is developing.
The first is that it has no reference implementation, and in places it seems to be drawn on gossamer threads around technical obstacles that have confronted a few major implementations. Unlike HTML, none of these privileged EPUB implementations have really gained market traction yet, but as they wax and wane, they leave their detritus in the spec. It appears that EPUB also has a mostly historical habit of gorging on other formats, a habit that might once have prevented it being boxed into a corner of irrelevance, but now creates bloat and dulls the gleam of the spec. There really need not be any provision for an EPUB to contain a PDF. The XML island stuff looks for all the world like an each-way bet — it could be scaled back significantly.
The specification MUST specify
Perhaps it is due to this lack of a canonical or dominant implementation that there comes a preference for the woollier words in RFC 2119: should, recommended, may and optional. Must, required and shall are ventured less frequently than a book designer or reading system developer might hope. And this is not abating. For example, although EPUB has a working metadata solution, the Working Group charter proposes “native support” for a handful of other metadata standards — as if by providing more options, they make the standard more standard. It’s rare to see a spec quite this promiscuous when it comes to other specs, and in my prudish opinion this gets it into trouble.
As a reading system developer, of course I want to see more clarity about what to support. I shouldn’t have to work with the multiple voodoo methods of identifying the (only probable) cover image for a book. I shouldn’t have to wonder why on earth that problem, or questions regarding other obviously bookish entities — like tables of contents or font sizes or footnotes — have gone apparently unaddressed.
But nor should a book designer. I think that’s important. Eventually, and not too distantly, production quality will become a differentiating factor for ebooks in the way that it is for print books now. The muck that Adobe InDesign emits will not be considered good enough, just as exporting your website from Microsoft Word is not good enough.
Then we can hope, if this ebook thing takes off, that an activist group of actual ebook designers emerges and begins pleading for simplicity and consistency. It is the absence of this vital lobby that I think is the second key problem with the manner and rate at which the EPUB spec is evolving.
Actual ebook designers would beg for level ground. For a single recommended way to mark up footnotes. They would campaign against the fetish for strictness in the spec — which among other things tells them to use the grouchy, disowned child that is XHTML 1.1, therefore to robotically obey its concomitant media type edicts (and therefore break so many otherwise workable ebooks, at least in my testing). They would probably push for some level of interactivity, but not as a priority, not as the thing that evolves ebooks into a whole new medium.
This is because, and perhaps I’m being starry-eyed about this mostly-missing bunch of radicals, these actual ebook designers would have some faith in their ability to make reading digital books as books a sufficiently compelling experience. Which neatly brings me to my dire warning. Tomorrow.
Sorry, comments are not available on this post.