Straw-Man Spec

Consider this a straw-man outline of the spec, as I envision it.

What’s inside?

1. An e0 file has file extension .e0
2. An e0 is a zipped folder which contains an index.html file
3. index.html is an HTML5 content file, and shall contain at least one nav element, unless index.html is the only HTML5 content file.
4. By default, the first nav element in index.html serves as both primary navigation (hereafter referred to as "toc") and as an indication of the reading order (hereafter referred to as "spine", in keeping with EPUB terminology). If an li element in the first nav in index.html is not otherwise marked, the referenced file should appear in both the reading system's primary navigation interface, and be part of the linear reading order.
5. If a file should be omitted from toc, but remain in the spine, use the hidden attribute on the list item. Among other things, this means that, in most cases, a web browser (that knows nothing of e0) opening up index.html will do the right thing.
6. If a file should be omitted from the spine, but remain in the primary toc, add role="toc" to the list item. We’re hoping this is quite rare.
7. If a file should be omitted from both the spine and toc, it should not appear in nav in index.html. There’s no obligation for all content documents to appear here.
8. An e0 reading system should not open index.html directly, but display the first content file referenced in the first nav in index.html (unless there's no nav in index.html). Ideally this first content file would be the book cover.
9. Document metadata lives in index.html. Section metadata can live in the individual content files. The metadata vocabulary is being discussed; for now use meta in the html head.
10. If there is a cover image, it should be referenced in index.html via link rel="cover"
11. Either the HTML or the XHTML serialization of HTML5 is allowed.
12. MathML and SVG in HTML5 documents are allowed.

What’s not?

1. There’s no mimetype file, META-INF folder, or container.xml file. Rather than using container.xml to point to the “root,” the reading system just needs to find index.html.
2. There’s no special method of zipping
3. There’s no package file.  index.html serves many of the same purposes, but tries to avoid duplication and non-HTML vocabularies. 
4. There’s no manifest. The computer can figure out what files are in the zip, and can probably figure out what kinds of files they are.
5. e0 does not have a CSS profile. 
6. Landmarks and guides are omitted. We already know where the toc and cover are. If you want the reader to begin reading at a specific place, put that place at the beginning of the book!

Principles

1. Simplicity
2. Avoid duplication
3. Use HTML vocabularies wherever possible
4. Make life easier for the content creator, even if that makes life harder for the reading system developer

e0 Incarnate, and a Note on Navigation

e0 Incarnate

The first e0 file is, of course, Moby-Dick, available for download here. Those of you who have followed the conversation will notice that it is much like the original proposal, with one exception.

A Note on Navigation, Reading Order, and index.html

The major change is the handling of the primary navigation in index.html. On the mailing list, we reached a consensus that the role attribute would be the primary method of adding semantics to HTML5 elements, thus avoiding namespaced attributes (epub:type), HTML5 data- attributes, and other such horrors.

The primary vocabulary for @role will be the EPUB3 Structural Semantics Vocabulary, extended as needed. How can this help with index.html? I'm hoping this will allow us to use a single nav element to function as both nav and spine.

For the first nav element in index.html, we will define the default behaviour to be as if every element was role="toc spine". This means:

1. The element appears in the default navigation structure ("toc")
2. The element appears in the document's linear reading order ("spine"), as in EPUB's linear="yes".

So if an element is marked as role="toc" it means it does appear in default nav, but is not in the default linear reading order. If an element is marked as role="spine" it appears in the linear reading order, but does not appear in default navigation. If you don't want either function, just leave the section out of index.html//nav[1]. There is no obligation to list all content documents in the e0 folder.

One can choose to hide the default navigation from displaying on the index.html page by using the hidden attribute.

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?