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

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.