Spineless, Part Two

As I've mentioned before, a major issue is how to deal with both reading order and navigation. Here's one possible solution.

“Easy Things should be easy.”

For many books, the reading order will closely follow navigation (or is it the other way around?)In this case, index.html just needs a single nav element:

<nav hidden="hidden"> 
  <h1>Contents</h1>
  <ol>
   <li><a href="s001-BookTitlePage-01.html">Title Page</a></li>
   <li><a href="s002-Preface-01.html">Original Transcriber’s Notes:</a></li>
   <li><a href="s003-Introduction-01.html">Etymology.</a></li>
   <li><a href="s004-Epigraph-01.html">Extracts (Supplied by a Sub-Sub-Librarian).</a></li>
   <li><a href="s005-Chapter-001.html">Chapter 1: Loomings</a></li>
   <li><a href="s006-Chapter-002.html">Chapter 2: The Carpet-Bag</a></li>
   <li><a href="s007-Chapter-003.html">Chapter 3: The Spouter-Inn</a></li>

The reading system will display each distinct file mentioned, in order. If we don't want this navigation file to be visible upon opening index.html, we can hide it. The reading system can still use this nav element to create its own navigation (as most current reading systems do with the NCX).

“Hard things should be possible.”

Other books may have more complex navigational needs, and the table of contents may not track the reading order (especially for things we'd currently describe with linear="no").

I still believe nav is the best fit in HTML5 for both a standalone reading order and navigation files. So why not let index.html contain as many nav elements as necessary, each of which may serve a different function? We would need some sort of vocabulary to identify these. As I want to avoid a special namespace like epub:type, I'd propose using a data-e0-type attribute (knowing there will be objections):

<nav hidden="hidden" data-e0-type="spine">
  <ol>
    <li><a href="file1.html">File 1</a></li>
    <li><a href="file2.html">File 2</a></li>
    <li><a href="file3.html">File 3</a></li>
  </ol>
</nav>
<nav hidden="hidden" data-e0-type="toc">
  <ol>
    <li><a href="file1.html">Chapter 1</a></li>
    <li><a href="file1-quiz.html">Chapter 1 Review</a></li>
    <li><a href="file2.html">File 2</a></li>
    <li><a href="file2-quiz.html">Chapter 2 Review</a></li>
    <li><a href="file3.html">Chapter 3</a></li>
    <li><a href="file3-quiz.html">Chapter 3 Review</a></li>
  </ol>
</nav>

This could be extended for page lists, lists of illustrations, and so on, using the appropriate attribute to describe the nature of the particular nav element.

Our earlier example could also be described as data-e0-type="spine toc".

Alternate Solution

Another proposal is to have a single nav for spine and toc, but have some sort of attribute on individual li elements to indicate if they are part of the linear reading order or not.

<nav hidden>
  <ol>
    <li><a href="file1.html">Chapter 1</a></li>
    <li hidden><a href="file1-quiz.html">Chapter 1 Review</a></li>
    <li><a href="file2.html">File 2</a></li>
    <li hidden><a href="file2-quiz.html">Chapter 2 Review</a></li>
    <li><a href="file3.html">Chapter 3</a></li>
    <li hidden><a href="file3-quiz.html">Chapter 3 Review</a></li>
  </ol>
</nav>

In this case, the hidden attribute is overloaded. The reading system would go directly from file1.html to file2.html; file1-quiz.html would only be accessible via link.

Mailing List

A Google Group has been created to informally discuss future directions for e-book specifications, especially those that are not backwards-compatible with existing specs.

https://groups.google.com/group/epub-ng

War

I just read two reviews of Sebastian Junger's War, in the New York Times and Washington Post. Both reviews mentioned the part titles, by name, in full. War is a very simple book, structurally, but illustrates some of the challenges we face with e-book navigation. The book consists of three parts:

Book One | Fear
Book Two | Killing
Book Three | Love

In print, this is the entire table of contents, and is essential to framing the story. In EPUB2, we typically have both an HTML table of contents (which we move to the end of the book) and the required NCX. Given the importance of this toc, we broke our rule about HTML tocs, and followed the print book. The NCX contained the links to all the chapters.

So how would we handle this in e0? We do need to define the reading order in index.html:

<nav>
  <ol>
    <li><a href="s003-preface.html">Author’s Note</a></li>
    <li><a href="s004-part-001.html">Book One | Fear</a></li>
    <li><a href="s005-chapter-000.html">New York City, Six Months Later</a></li>
    <li><a href="s006-chapter-001.html">1. Korengal Valley, Afghanistan, Spring 2007</a></li>
    <li><a href="s007-chapter-002.html">2.</a></li>
    <li><a href="s008-chapter-003.html">3.</a></li>
  </ol>
</nav>

But we don't want the reader to see that as a primary part of the text, so I'll make it hidden. Do I then need to define the reading order separately from the navigation? I don't think so, in this case. This works fine both to define the reading order and provide machine-readable navigation for the reading system. So what should I do? I'll just add an old-fashioned table of contents, as a regular content file, after editing my index.html.

<nav hidden="hidden">
  <ol>
    <li><a href="s002-toc.html">Contents</a></li>
    <li><a href="s003-preface.html">Author’s Note</a></li>
    <li><a href="s004-part-001.html">Book One | Fear</a></li>
    <li><a href="s005-chapter-000.html">New York City, Six Months Later</a></li>
    <li><a href="s006-chapter-001.html">1. Korengal Valley, Afghanistan, Spring 2007</a></li>
    <li><a href="s007-chapter-002.html">2.</a></li>
    <li><a href="s008-chapter-003.html">3.</a></li>
  </ol>
</nav>

and in s002-toc.html:

<nav>
  <ol>
    <li><a href="s004-part-001.html">Book One | Fear</a></li>
    <li><a href="s012-part-002.html">Book Two | Killing</li>
    <li><a href="s021-part-003.html">Book Three | Love</li>
  </ol>
</nav>

This example turned out to be simpler than I hoped. I'd love to see examples of more complex navigational structures, especially if they seem to conflict with this simple approach to defining the reading order.

index.html and "One Big File"

The heart of our format (which I'll call e0, after Richard Pipe) is index.html. The book opens to index.html, and the reading system shows us what's there (unless it's marked hidden, as HTML5 allows us to do).

So it's entirely possible to create an .e0 file that consists only of index.html in the zip. However, I think that requiring all content to be in index.html is too restrictive. Partly I'm just lazy; having split hundreds of single-file e-books into chunks in 2007–2008, I don't want to do the reverse. But some books are not all the same thing.

I think the clearest example is with metadata. If we put book metadata into meta on the index.html file, we can put chapter-specific metadata in meta in a chapter file. EPUB can't do that! With a short story collection, the editor can be cited in index.html, and each author in the component HTML file containing their work.

Styles may differ between sections, and books may even alternate between reflowable and fixed layouts.  Portions of books may be mixed together; I'd rather drag the new file into a folder and make a single edit to my nav file (in index.html) than paste a bunch of new content into a giant file. And heaven forbid if you muck up the nesting of divs in a forty-thousand-line file!

So make One Big File if you like. But maybe someone else's books may benefit from having more than one.

Spineless

I must say I'm surprised by how much conversation this has generated. After writing the first post late one night, I emailed the link to two people, and went to bed. When I woke up there were hundreds of page views.

Based on the discussion, the two areas of greatest controversy interest are [1] nav vs. spine and [2] metadata. Let's talk about the spine.

From the EPUB3 spec:

The spine element defines the default reading order of the EPUB Publication content by defining an ordered list of manifest item references.

The spine represents an ordered subset of the Publication Resources listed in the manifest, with content items not being referenced being ancillary to those that do.

Reading Systems must provide a means of rendering a Publication in the order defined by the spine, which includes: 1) recognizing the first primary (linear='yes') item in the spine as the beginning of the main reading order of the Publication; and, 2) rendering successive primary items in the order given in the spine.

So a component that isn't in the spine is "ancillary" to the main content. This is interesting, because no such burden is placed on nav. In fact, for some FXL children's books, our nav file consists of a single entry, labelled "begin reading." That label reminds us there is text associated with each entry in a nav element, the title of the thing you're pointing to. So we have one thing (spine) that is required to point to all the "primary" components of the document, but has no obligation to name those components. And we have a different thing (nav) that is required to name any component it points to, but is (mostly) optional.

EPUB Zero proposes that index.html contain at least one nav element, which would identify the primary reading order of a document based on the content documents (not necessarily html) referenced.

So in some sense we're requiring the main navigation document to identify and label every component of the primary reading order, which is a greater constraint than in EPUB3. Could this raise the baseline for accessibility?

If we do this, the primary navigation document could not refer to files that are not in the linear reading order. Is this too high a price to pay? Is there a class of documents that aren't important enough to be in the main flow, but too important to omit from the primary nav file? I believe I could happily live with such a restriction, but I wonder what others think. [keep in mind there would be no restriction on linking to 'out-of-spine' content].

If we separate the functions of navigation and reading order, how would we describe the reading order using only HTML5? If there is a "navigation" nav file, and a "reading order" nav file, how do we distinguish them?

EPUB Zero: a radically simple(r) e-book format

Earlier this week, I participated in the W3C Workshop on Electronic Books. A common theme was the complexity of the EPUB3 specification, how difficult it was to implement, and how few implementations exist.

These ideas were expressed most forcefully by Daniel Glazman (slides available here as PDF). I'd been familiar with some of his thoughts, as he'd posted extensively about his experience with EPUB3 as he implemented an EPUB3 editor. His rant about the absurd number of navigation files particularly resonated with me. Why do we need a manifest, a spine, an NCX, a nav document, landmarks, and guides?

What would an e-book look like, if we tried to avoid as much complexity as possible? The idea wouldn't go away. I try to avoid abstract thinking, and so my natural reaction was to build a sample book and see what happened. So I'm in the middle of that process, with Moby-Dick, of course. Let me know if you want me to email you a copy.

PRINCIPLES

The goal is for an e-book to be as simple as possible, and as close to the web as possible. Is it possible to make an e-book without any e-book-specific features? Do we need anything beyond bog-standard HTML5, CSS, JavaScript, SVG, MathML, and media? I'd like to find out.

Another goal is to make authoring easier. I wonder how much of the complexity of previous e-book specifications was to make life easier for reading system developers, who have course been the major participants in the standards bodies (not that there's anything wrong with that!).

INSIDE EPUB ZERO

The Container

An EPUB Zero file is a zipped folder containing only content files. It's identified by the file extension. There is no mimetype, no META-INF, no container.xml. And so the zip process is much simpler, your operating system's zip command should work without changes. None of this

zip -v0X $FOLDER mimetype
zip -vr $FOLDER * -x $FOLDER mimetype

bullshit.

The Package

The heart of an EPUB Zero is the index.html file. The reading system (if they were ever to exist) would look inside the zip for index.html. This file provides navigation (via the nav element), defines the order of content documents (via the nav element!), and contains document metadata (see below). Not all content documents need to be in the nav element; if they're in the zip you can reference them via links and have an "out of spine" item. Same goes for images, as well as audio, and video (perish the thought).

An open question is how to define what happens when the book first opens. You might not want to see a complex table of contents as soon as you open a book. Perhaps if the nav element is hidden, the reading system would then just open the first document referenced by nav.

Metadata

I'm unsure how to handle metadata. My first thought was to use the head of index.html:

<meta charset='utf-8'> 
    <title>Moby-Dick</title>
    <meta name="dcterms.creator" content="Herman Melville"/>
    <meta name="dcterms.title" content="Moby-Dick"/>
    <meta name="dcterms.identifier" content="x9780000000000"/>
    <meta name="dcterms.language" content="en"/>
    <meta name="dcterms.modified" content="2013-02-14"/>
    <meta name="dcterms.publisher" content="Harper & Sons"/>

That strikes me as inadequate. Would this be enough for the very simplest cases, in conjunction with some sort of link to an ONIX record? The middle ground here seems like dangerous ground, as we always want to handle "one more thing…"

Content Documents

All content documents are HTML5, which of course can contain SVG and MathML. I reserve the right to use the XML serialization for any EPUB Zero I produce :)

WHAT IS AN EBOOK?

When you go to a website, you navigate through the content by clicking on links, going from page to page. What makes an e-book different is that the sequence of pages is defined ahead of time, and the reading system helps the reader navigate. Does this mean that a plain web browser won't work as a (packaged) e-book reader, without some sort of extension or scripting?

WHAT NEXT?

I haven't thought about how accessibility would work in this context, or digital rights management (could a digital signature work with this file structure?), or many other things. Maybe the ultimate answer is that we need the complexity of the existing specs. But I'd prefer to be convinced that this is too simple, rather than assume that what we have is just right.

Dave (writing, of course, as a private citizen)