“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.
you've lost the "simple" plot, dave.
ReplyDeletehere's my file-format for moby-dick:
> http://zenmagiclove.com/zml/mobyd/mobyd.zml
if you're thinking that looks like
a simple text-file, you're right...
well, at least, you're mostly right.
it's actually a structured text-file,
because there is some zen markup
hiding in plain sight in the whitespace.
but that's what it means to be "simple".
we make the file-format simple, so that
the humans can produce e-books easily,
and we put the smarts in the viewer-app,
because that's where they're most efficient.
and yeah, we still have to deal with those
browsers, which are programmed to be
stupid rule-following robots who need to
be fed .html, so here's the .html file we'll
"back-convert" for your dumb browsers:
> http://zenmagiclove.com/zml/mobyd/mobyd.html
and my .html might not strike your fancy,
but it's easy enough to recode it so it will,
if you just describe your preferred markup.
and yes, we can (and do) make an .epub,
and a .mobi, and a .pdf, and offline apps,
and online apps, heck, even a _slideshow_.
all of 'em high-quality, from the .zml file.
and nobody ever has to deal with an .ncx,
or an .opf, or any other stupid acronyms.
because we want e-books to be simple.
and ordinary people don't think that your
acronyms are simple... they really don't...
-bowerbird
the silence is pretty loud in here...
ReplyDelete-bowerbird
The conversation is quite lively elsewhere, as was mentioned in the previous post.
ReplyDeletethat "conversation" has nothing to do with "simple".
ReplyDeleteindeed, it is so far removed, i won't even go there...
(the acronyms alone are enough to choke a horse!)
but as soon as y'all get your version worked out,
_my_ "simple" will be waiting to steal your lunch.
-bowerbird
hey dave-
ReplyDeletei finally got around to testing some of your concerns
in my lab, so i thought i report back with my findings.
i've created a mac e-book app with a _lot_ of content
-- including a 12m text file, a 7m video, a .5m mp3,
and over 3000 images, summing to well over 100m.
further, as you probably know, a mac program is just
a _folder_, which means you can open it in the finder,
and burrow down to that content and replace it at will,
meaning you can not just verify the content i described,
but also substitute in your own, to make sure it's "real".
(you'll need to use the same filenames that i used, but
other than that, everything will continue to work nicely.)
as for "working", i just stuffed the text into a text-field,
so you can actually edit it live. and the video and mp3
do play normally, as you would expect. the cursor-keys
will thumb you through the paragraphs of the text-file
(it's moby dick), one by one, with each one summoning
one of the 3000+ graphic-files (the one which was used
as the "content" that created the image, as can be seen).
anyway, this app is 136m, but if you want me to send it
over some way so you can take a look, you let me know.
what you will see, if you do look at it, is that it remains
very snappy, even with the audio and the video playing,
and can slide through the paragraphs much faster than
you could read them, or even get a good view of them...
ergo, i've got an excellent handle on "container" issues.
-bowerbird
dave-
ReplyDeletetoday's task is to program some download routines.
that way, i'll be able to send you the bare app itself,
and it will grab all the content from the web. better.
-bowerbird
Cool. I don't have an FTP that's not tied to my employer :)
Deleteok, coded it. and already done with today's addition, too,
ReplyDeletewhich only took minutes, but what a boost in capability!
my new feature, in this offline viewer-app, provides a link
for each displayed paragraph, which opens in your browser
the online version of the book at the very same paragraph.
so you can be instantly transported from the offline version
of the book to the very same spot in the online version of it.
this provides some synergy between the offline and online
versions, helping to jumpstart stuff like online annotations
and conversations that focus on specific parts of the book.
such synergy might be on .epub's drawing-boards, or not,
but i already have it, and it just "fell out of" my approach...
anyway, dave, send me your e-mail if you're interested in
taking a look at this. if not, just consider this an f.y.i. :+)
-bowerbird
My email is my twitter name, followed by the name of Google's email service :)
Delete