The Genesis of Pagination

1 In the beginning THE DIRECTOR created the CANVAS.

2 And THE CANVAS was without form, and void; and darkness was upon the face of the deep. And the Spirit of THE DIRECTOR moved upon the face of the waters.

3 And THE DIRECTOR said, Let there be CONTENT: and there was CONTENT.

4 And BERT saw THE CONTENT, that it was good: and BERT divided THE CONTENT from THE STYLE.

5 And BERT called the content THE ELEMENT TREE, and the darkness he called STYLE. And the evening and the morning were the first day.

6 And BERT said, Let there be a BOX TREE in the midst of the canvas, and let it unite THE ELEMENT TREE and the STYLE.

7 And BERT made A DOCUMENT, and rendered the fragmentainers of THE BOX TREE onto THE CANVAS: and it was so.

8 And THE DIRECTOR called the DOCUMENT valid. And the evening and the morning were the second day.

9 And PETER said, Let the makers of standards be gathered together unto one place, and let THE STANDARD appear: and it was so.

10 And PETER called THE STANDARD "CSS-OVERFLOW"; and the gathering together of the makers called he THE WORKING GROUP: and THE DIRECTOR saw that it was good.

CSS Drop Caps

 The following is a copy of a tiny presentation given at the CSS Working Group F2F meeting in Seoul earlier in May. I've posted this only so that the minutes may link here, helping explain what we were talking about. 

—Dave

---

CSS Drop Caps Initials Letters

Initial Letters on the Web are Broken:

 

Today's CSS

span.dropcap {

  float: left;
  font-size: 5.3em;
  line-height: .85em;
  margin-bottom: -.1em;
}

Garamond: Looks OK

Georgia: Same CSS, but alignment is bad

Palatino: Also Bad

Correct

Proposal

p::first-letter {
  drop-initial-value: 3;
}

Uh-oh

InDesign Controls

Sunken Caps

 

Footnotes as CSS Regions

 The following is a copy of a tiny presentation given at the CSS Working Group F2F meeting in Seoul earlier in May. I've posted this only so that the minutes may link here, helping explain what we were talking about. 

—Dave

---

Having to read footnotes resembles having to go downstairs to answer the door while in the midst of making love.

—Noël Coward

Current Footnote Syntax in GCPM

span.footnote { float: footnote }

@page {
    @footnote {
        float: bottom;
    }
}

footnote::call { content: counter(footnote) }
footnote::marker { content: counter(footnote) }

Issues with Current Approach

1. How to extend to multiple footnote areas?
2. How to handle columns?
3. What if the footnote is itself a block element?
4. It's magic all the way down

Proposal using Regions and Pagination Templates

span.footnote {
  flow-into: footnote;
}

span.footnote::before {
  content: counter(footnote) '. ';
}

@page {
  @slot footnote {
    flow-from: footnote;
    required-flow: footnote;
    position: absolute;
    left: 54pt;
    bottom: 0pt;
    width: 352pt;
    height: auto;
    border-top: .25pt solid black;
    vertical-align: bottom;
  }
}

 The Good News

1. Easily extended for multiple footnote regions and sidenotes
2. Good way to suppress footnote area if there are no footnotes on the page.
3. Doesn’t require float for the footnote element
4. Regions rule!!

The Bad News

1. Change of syntax from existing implementations
2. How do you create footnote reference?
3. How do define constraint that footnote stays on same page as reference?
4. Still requires magic

Running Heads using Regions

h1 {
  flow-into: chapter-title;
  flow-options: static; /* so not "consumed" by flow */
}

@page {
  @top-center {
    flow-from: chapter-title;
    font-size: 10pt;
    font-variant: small-caps;
    letter-spacing: 1pt;
    }
}

@page {
  @top-center {
    content: string(header);
    }
}

 

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