(x)html ebook specification

[pepak]

Originally Posted by rogue_ronin

Hmmm, another thought. Does it make sense to include the following two things?

It does make sense, but seems a bit too detailed to me. It may be interesting, but:
- the book should never leave your computer in the intermediate stages
- after version 1.00, most of the changes will be along the lines of "fixed typo on page 123 line 15".

#2: structure hints. Should someone have to examine the entire source for a clue to how it's been assembled? Or could you add something like this as a comment?:

Personally, I prefer the "no-clue" approach. If someone wants to see the clues, he can easily do that (for all books at one stroke) by modifying CSS, e.g.

h1.title:before { content: "Title: "; }

But once again, I must stress that I do the books for myself, to suit my needs, and not for public consumption. If you want to provide a standardized framework, the opposite approach might be better - if you use a proper tagging, hiding all "clues" would be even easier:

.clue { display: none; }

[rogue_ronin]

Originally Posted by pepak

You may want to contact a proofer or another - so you need an e-mail and possibly some IM. You can add them to the list (into parentheses, or something), but if the amount of data still increases, the list will become even less readable.

Hadn't thought of contacting them, that makes sense. Given the below comments, I think I would go with putting them into parentheses.

Do you have any specific reason why you don't want to use multiple meta's?

<meta name="proofer" content="Person A" />
<meta name="proofer" content="Person B" />
<meta name="proofer" content="Person C" />

Consistently, you could do all multiple-value metas this way, e.g. for author. Reason being, it makes sense to place a book by A. Smith and B. Johnson both among "Smith books" and "Johnson books".

I assumed that all the meta names needed to be unique. If they don't, then I'm for not numbering them, and just adding multiple meta's as necessary.

Personally, I prefer the SQL-standard of yyyy-mm-dd, which is easy to sort even in textual form.

Just as easy the other way, and closer to how we (well, americans) speak. At least I'm abandoning the american, mmm/dd/yyyy, which is the way it is because it's exactly the way we speak. Plus, I'll get confused if I do it that way, I know I will.

Oh, and looking at your example, I realize I didn't terminate the meta tags with />...

m a r

[rogue_ronin]

Originally Posted by pepak

It does make sense, but seems a bit too detailed to me. It may be interesting, but:
- the book should never leave your computer in the intermediate stages
- after version 1.00, most of the changes will be along the lines of "fixed typo on page 123 line 15".

Your analysis of my words is correct, but I might release earlier -- some of the sources I don't have, so I cannot go past 0.80 on that scale, yet there's no reason to keep them locked up on my hard drive. I should probably reword as follows:

   0.10 Initial Conversion
   0.20 Cover and Frontispiece
   0.30 Sections, Chapters and TOC
   0.40 Endnotes and/or Blockquotes
   0.50 Initial Spellcheck
   0.60 Mdashes and Hyphens and Ellipses
   0.70 Italics, Bold, and Pre-Formatted Text
   0.80 Reading Proof
   0.90 Checked Against Canonical Source
   1.00 Final Version -- Optimal
 1.00+ Minor Error Corrections

I think that including it would suggest to someone how to add value and version it consistently. I can think of arguments for releasing at 0.50 and 0.60 as well.

Personally, I prefer the "no-clue" approach. If someone wants to see the clues, he can easily do that (for all books at one stroke) by modifying CSS, e.g.

h1.title:before { content: "Title: "; }

You've got me there, I can't follow you yet -- just starting to get into the CSS.

If you use a proper tagging, hiding all "clues" would be even easier:

.clue { display: none; }

I assume you mean to put the "clues" into a special container. I'm just thinking to put it into a comment. Could you explain more fully?

Thanks as always for your insightful comments,

m a r

ps: did you start your regex thread?

[rogue_ronin]

So, minor update after discussion above:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<title>A Princess of Mars</title>

<!-- BEGIN: DOCUMENT HISTORY -->

<!-- Created on 20/May/2004 -->
<!-- Revision # 0.10 on 30/Jun/2004 -->
<!-- Revision # 0.20 on 28/Dec/2004 -->
<!-- Revision # 0.40 on 13/Apr/2005 -->
<!-- Revision # 0.70 on 30/Sep/2006 -->
<!-- Current Revision # 0.80 on 18/May/2009 -->

<!-- END: DOCUMENT HISTORY -->

<!-- BEGIN: REVISION GUIDELINE -->

<!--
   0.10 Initial Conversion
   0.20 Cover and Frontispiece
   0.30 Sections, Chapters and TOC
   0.40 Endnotes and/or Blockquotes
   0.50 Initial Spellcheck
   0.60 M-dashes and Hyphens and Ellipses
   0.70 Italics, Bold, and Pre-Formatted Text
   0.80 Reading Proof
   0.90 Checked Against Canonical Source
   1.00 Final Version -- Optimal
 1.00+ Minor Error Corrections
-->

<!-- END: REVISION GUIDELINE -->

<!-- BEGIN: EBOOK META INFORMATION -->

<meta name="filename" content="APrincessOfMars" />
<meta name="fileid" content="FoundText0085" />
<meta name="filecreationdate" content="20/May/2004" />
<meta name="fileversion" content="0.80" />
<meta name="filerevisiondate" content="18/May/2009" />
<meta name="filesource" content="University of Virginia Electronic Text Center" />
<meta name="filescanner" content="Judy Boss" />
<meta name="fileproofer" content="Kelly Tetterton" />
<meta name="fileproofer" content="Peter-John Byrnes" />
<meta name="fileproofer" content="Found Text (foundtext@gmail.com)" />

<meta name="title" content="A Princess of Mars" />
<meta name="subtitle" content="Barsoom #01" />
<meta name="series" content="Barsoom" />
<meta name="seriesnumber" content="01" />
<meta name="genre" content="Science Fiction::General" />

<meta name="author" content="Edgar Rice Burroughs" />
<meta name="authorlast" content="Burroughs" />
<meta name="authorfirst" content="Edgar" />
<meta name="authormiddle" content="Rice" />
<meta name="authoralpha" content="Burroughs, Edgar Rice" />

<meta name="illustrator" content="Frank Frazetta" />
<meta name="illustratorlast" content="Frazetta" />
<meta name="illustratorfirst" content="Frank" />
<meta name="illustratormiddle" content="" />
<meta name="illustratoralpha" content="Frazetta, Frank" />

<meta name="publisher" content="Found Text" />
<meta name="publicationdate" content="08/July/2010" />
<meta name="publicationcity" content="Honolulu" />
<meta name="publicationcity" content="Bangkok" />

<meta name="copyrightholder" content="" />
<meta name="copyrightdate" content="" />

<meta name="isbn" content="" />

<!-- END: EBOOK META INFORMATION -->

<!-- BEGIN: STRUCTURE HINTS -->

<!--
Title: h1 class="title"
Subtitle: h3 class="subtitle"
Chapter: h3 class="chapter"
Paragraph: p class="normal"
Epigram: p class="epigram"
Psionic: em class="psionic"
etc. etc.
-->

<!-- END: STRUCTURE HINTS -->

</head>

I'm sort of liking this; I think it achieves two things -- it is parseable for utilities/macros and it is human-readable and human-editable. Oh, and completely invisible to a person just reading the book. Hopefully it puts everything that you need to know about the following file right at the top, where you can use it to re-write CSS, or pick a version number, or whatever.

If for some reason a person only had this file, would it be easy to recreate the rest?

I guess the final thing it could need is a manifest of image/sounds that it references.

m a r

[pepak]

Originally Posted by rogue_ronin

I assume you mean to put the "clues" into a special container. I'm just thinking to put it into a comment. Could you explain more fully?

You should definitely read up on CSS, it will make things a lot more clear. But, without going into details, there are three main "identifiers" of what a given CSS option-set should affect:
something { ... } - this CSS applies to tag something
.something { ... } - this CSS applies to any tag that has (or contains) a class something
#something { ... } - this CSS applies to any tag that has id (or name) something.
You can combine and nest these identifiers, but that's not important. The important thing is that if you put your "clues" into your document as either a special tag, or as a tag with a given class, you could style them using CSS quite easily, including the possibility to hide the clue altogether.

E.g. <h2><clue>Chapter:</clue> Chapter 10</h2> could use a styling such as clue { display: none; }.

The problem with the above example is that there is no clue tag in XHTML - you would have to define it yourself. That's why you may want to prefer to use e.g. a span: <h2><span class="clue">Chapter:</span> Chapter 10</h2> and hide it with .clue { display: none; }.

ps: did you start your regex thread?

Nope. I will add to it if someone starts it, but I don't want to start it myself.

[pepak]

But, on the other hand, it would be just as simple to use:
<h2 class="chapter">Chapter 10</h2> and .chapter:before { content: "Chapter: "; }, which saves on one tag, or even
<div class="chapter"><h2>Chapter 10</h2><p>...</p><p>...</p></div>, which keeps an extra tag (div), but makes a clear distinction of where a chapter begins and ends (h2 only marks where the chapter's title begins and ends, not the chapter itself; it is only implied that a chapter ends where a next chapter begins, but that may not necessarily be true for all books).

[rogue_ronin]

Okay, I read the W3C Schools CSS tutorial yesterday, I'm following you better. 'Course, I'm not a wizard. Yet.

Yeah, I posted above you with my current solution. I'll be adding a manifest, then I think I'm pretty complete with meta -- but of course, I'm still open to suggestions/improvements.

I don't want to clutter the markup with too many classes and pseudo-classes. At least for the meta-info, I'd pretty much like to keep it all in the head, and use it consistently so that it becomes easy for anyone to write new CSS, to extract data for conversion to other formats, etc.

And I think I disagree with you only because I don't want any of this stuff to appear in the book as one reads (except for some stuff in the verso) so there's no reason to add more code to obscure it or reveal it. It's just there for tools/utilities, and for reference when someone wants to look under the hood for any reason. Meta on the structure is just a polite thing: "Here's every element, class and relevant ID we're using in the document, and how we're using them -- no need to try to determine it all again by hand and eye."

Not home now, but I'm gonna keep going with this. I'll add the manifest next, then I think I'll move on to determining elements and classes and etc. for the various pieces of a book.

Your comments about <h> vs. <div>s are right on (and thanks for educating me regarding <div>s.) I'll definitely be doing that, or some variant of it.

m a r

[gwynevans]

There's some CSS 'RefCardz'(!) at DZone that might be worth a look
- http://refcardz.dzone.com/refcardz/corecss-part1
- http://refcardz.dzone.com/refcardz/corecss2 &
- http://refcardz.dzone.com/refcardz/corecss3

Registration required, but it's a legit site.

[rogue_ronin]

Originally Posted by gwynevans

There's some CSS 'RefCardz'(!) at DZone that might be worth a look
- http://refcardz.dzone.com/refcardz/corecss-part1
- http://refcardz.dzone.com/refcardz/corecss2 &
- http://refcardz.dzone.com/refcardz/corecss3

Registration required, but it's a legit site.

They look good, but I'm remaining anonymous!



m a r

[rogue_ronin]

Back home again for a while, so here we go...

I think this will do as a tentative final format for the head, and all meta info. You can't use <div>s in the head, right?

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

<head>

<title>A Princess of Mars</title>

<!-- BEGIN: DOCUMENT HISTORY -->

<!-- Created on 20/May/2004 -->
<!-- Revision # 0.10 on 30/Jun/2004 -->
<!-- Revision # 0.20 on 28/Dec/2004 -->
<!-- Revision # 0.40 on 13/Apr/2005 -->
<!-- Revision # 0.70 on 30/Sep/2006 -->
<!-- Current Revision # 0.80 on 18/May/2009 -->

<!-- END: DOCUMENT HISTORY -->

<!-- BEGIN: REVISION GUIDELINE -->

<!--
   0.10 :: Initial Conversion
   0.20 :: Cover and Frontispiece
   0.30 :: Sections, Chapters and TOC
   0.40 :: Endnotes and/or Blockquotes
   0.50 :: Initial Spellcheck
   0.60 :: M-dashes and Hyphens and Ellipses
   0.70 :: Italics, Bold, and Pre-Formatted Text
   0.80 :: Reading Proof
   0.90 :: Checked Against Canonical Source
   1.00 :: Final Version -- Optimal
 1.00+ :: Minor Error Corrections
-->

<!-- END: REVISION GUIDELINE -->

<!-- BEGIN: EBOOK META INFORMATION -->

<meta name="filename" content="APrincessOfMars" />
<meta name="fileid" content="FoundText0085" />
<meta name="filecreationdate" content="20/May/2004" />
<meta name="fileversion" content="0.80" />
<meta name="filerevisiondate" content="18/May/2009" />
<meta name="filesource" content="University of Virginia Electronic Text Center" />
<meta name="filescanner" content="Judy Boss" />
<meta name="fileproofer" content="Kelly Tetterton" />
<meta name="fileproofer" content="Peter-John Byrnes" />
<meta name="fileproofer" content="Found Text (foundtext@gmail.com)" />

<meta name="title" content="A Princess of Mars" />
<meta name="subtitle" content="Barsoom #01" />
<meta name="series" content="Barsoom" />
<meta name="seriesnumber" content="01" />
<meta name="genre" content="Science Fiction::General" />

<meta name="author" content="Edgar Rice Burroughs" />
<meta name="authorlast" content="Burroughs" />
<meta name="authorfirst" content="Edgar" />
<meta name="authormiddle" content="Rice" />
<meta name="authoralpha" content="Burroughs, Edgar Rice" />

<meta name="illustrator" content="Frank Frazetta" />
<meta name="illustratorlast" content="Frazetta" />
<meta name="illustratorfirst" content="Frank" />
<meta name="illustratormiddle" content="" />
<meta name="illustratoralpha" content="Frazetta, Frank" />

<meta name="publisher" content="Found Text" />
<meta name="publicationdate" content="08/July/2010" />
<meta name="publicationcity" content="Honolulu" />
<meta name="publicationcity" content="Bangkok" />

<meta name="copyrightholder" content="" />
<meta name="copyrightdate" content="" />

<meta name="isbn" content="" />

<!-- END: EBOOK META INFORMATION -->

<!-- BEGIN: STRUCTURE HINTS -->

<!--
<h1 class="title"> :: Title of book
<h2 class="subtitle"> :: Subtitle of book
<h3 class="chapter"> :: Chapter headings
<p class="normal"> :: regular paragraph
<p class="epigram"> :: quotation that opens chapters
<em class="psionic"> :: telepathic communication
etc. etc.
-->

<!-- END: STRUCTURE HINTS -->

<!-- BEGIN: MANIFEST -->

<!--
APrincessOfMars.html :: main document, this file
images\cover.png :: cover image, 1-bit, 314x480px
images\arrow_down.png :: chapter navigation down button, 1-bit, 30x30px
images\arrow_up.png :: chapter navigation up button, 1-bit, 30x30px
images\bar.png :: decoration, 1-bit, 150x9px
images\book_plate.png :: series logo, or frontispiece image, 1-bit, 314x224px
images\end_of_book.png :: colophon image, closes book, 1-bit, 250x170px
images\logo.png :: publisher logo, 1-bit, 70x70px
images\return.png :: endnote return button, 1-bit, 40x13px
images\toc.png :: navigation button, links to Table of Contents, 1-bit, 30x30px
sounds\logo.wav :: publisher logo sound, 8 bit, unsigned single channel (mono), 16khz sample rate, 16KB/s
-->

<!-- END: MANIFEST -->

</head>

Using the format of "item :: description" for the comments/info. The structure hints are the actual tag, the manifest uses relative path.

I guess that leaves me with only two questions remaining for meta info: 1) If <div>s can be used in the head, then maybe the BEGIN and END comments should be changed to <div>s? And 2) When/if there are more than one author or illustrator, should there be a numbering system -- as there are 4 entries for each name, would it be easier (or necessary) to parse based on numbers or positioning?

Moving on to structure, this is what I'm thinking most books have. I got a lot of this from a page on book structure years ago, from the "George A. Smathers Libraries Digital Library Center". (The page is gone now.)

I've modified some of the pieces a bit for ebook use...

1. Cover (links to the first of Preface, Foreword, Part or Chapter; quick start)
2. Frontispiece (Half-title, illustration, and/or series list)
3. Front Matter (generic for pre-book junk)
4. Title Page (Title, Author, Illustrator)
5. Verso Page (book meta info page)
6. Inscription ("To So-and-So")
7. Acknowledgments ("Thanks!")
8. Preface (usually by another author/editor)
9. Table of Illustrations/Maps (with links)
10. Table of Contents (with links)
11. Foreword (comments by the author)
12. Parts (sometimes called "Books", has navigation links)
    • Prologue (has navigation links)
    • Chapters (has navigation links)
      1. Chapter Title (name of the chapter)
      2. Epigrams (quotations that open chapters)
      3. Illustrations/Images/Maps/Tables
      4. Scene Break (blank lines or "* * *")
      5. Sections
         • Sub-Sections
           • Paragraphs
      6. Pull-Quotes (quotations from the text)
    • Epilogue (has navigation links)
13. Afterword (comments by the author, has navigation links)
14. About the Author Page (pic and bio)
15. Colophon (production notes and link to cover -- "closes" book)
16. Endnotes (definitely linked and back-linked)
17. Glossary (possibly with links)
18. Index (preferably with links)
19. End Matter (generic for post-book junk)

Is there anything else I should add, remove, rename or re-arrange? Next step will be to pick tags for each piece, once I'm happy with the overall structure. Not every book has everything, I'm just trying to come up with a master structure that should serve 90%, or more, of books.

m a r

[pdurrant]

I don't think you should be so prescriptive about the order of things between the cover and the parts.

Indeed, in a fiction ebook I much prefer to nearly all that stuff at the back of the book, with links to it from the contents menu.

Originally Posted by rogue_ronin

1. Cover (links to the first of Preface, Foreword, Part or Chapter; quick start)
2. Frontispiece (Half-title, illustration, and/or series list)
3. Front Matter (generic for pre-book junk)
4. Title Page (Title, Author, Illustrator)
5. Verso Page (book meta info page)
6. Inscription ("To So-and-So")
7. Acknowledgments ("Thanks!")
8. Preface (usually by another author/editor)
9. Table of Illustrations/Maps (with links)
10. Table of Contents (with links)
11. Foreword (comments by the author)
12. Parts (sometimes called "Books", has navigation links)
    • Prologue (has navigation links)
    • Chapters (has navigation links)
      1. Chapter Title (name of the chapter)
      2. Epigrams (quotations that open chapters)
      3. Illustrations/Images/Maps/Tables
      4. Scene Break (blank lines or "* * *")
      5. Sections
         • Sub-Sections
           • Paragraphs
      6. Pull-Quotes (quotations from the text)
    • Epilogue (has navigation links)
13. Afterword (comments by the author, has navigation links)
14. About the Author Page (pic and bio)
15. Colophon (production notes and link to cover -- "closes" book)
16. Endnotes (definitely linked and back-linked)
17. Glossary (possibly with links)
18. Index (preferably with links)
19. End Matter (generic for post-book junk)

Is there anything else I should add, remove, rename or re-arrange? Next step will be to pick tags for each piece, once I'm happy with the overall structure. Not every book has everything, I'm just trying to come up with a master structure that should serve 90%, or more, of books.

m a r

[rogue_ronin]

So, you would have:

Cover
Table of Contents
Parts, Chapters, etc
Everything that normally comes before the Parts
Afterword, etc.

Is that right? Do you do this so that you can get right into the book? Does your reader have a touchscreen, or way to navigate links?

m a r

[pdurrant]

Personally, I'd have

Cover
Title Page
(Possibly Dedication)
Parts
Everything else

I generally read Mobipocket format eBooks. They have a "Go To" menu that's usually populated with links to Start of Book, Table of Contents, etc. So to navigate in the book, I just bring up that menu and choose.

For example, the book I'm reading now "Morality for Beautiful Girls" has the following items on the "Go To" menu:

First Page
Start Reading
Table of Contents
Last Page

So getting to the Table of Contents takes the same time no matter where it is. So there's no point in having it at the front, although this book does do that.

I have a CyBook, so no touch screen. When reading a book it's quite quick to being up the main menu, select to the Go To menu, and then choose a desination from there.

Originally Posted by rogue_ronin

So, you would have:

Cover
Table of Contents
Parts, Chapters, etc
Everything that normally comes before the Parts
Afterword, etc.

Is that right? Do you do this so that you can get right into the book? Does your reader have a touchscreen, or way to navigate links?

m a r

[pepak]

Originally Posted by rogue_ronin

Back home again for a while, so here we go...

A few comments:
- I think you will have trouble with authorfirst/authorlast/illustratorfirst/illustratorlast if a book has multiple authors/illustrators.
- The classes seem superfluous: Personally, I prefer to use classes only to modify the default structural information. E.g. <h1>, as the "top header", is always used for title, unless class specifies something else. Similarly, <p> is always a common paragraph; I will only add class if I want to specify that it is not a normal paragraph after all.
- Not sure what would the navigation buttons be used for.

You can't use <div>s in the head, right?

You can't.

1) If <div>s can be used in the head, then maybe the BEGIN and END comments should be changed to <div>s?

You can't. Even if you could, that would make the metainformation visible, which is not a good thing, IMO.

And 2) When/if there are more than one author or illustrator, should there be a numbering system -- as there are 4 entries for each name, would it be easier (or necessary) to parse based on numbers or positioning?

I would combine all info about one author into one meta, then used multiple instances of said meta to describe multiple authors:

<meta name="author" content="Raymond E. Feist|Feist|Raymond E.|feist@midkemia.com" />
<meta name="author" content="Janny Wurts|Wurts|Janny|" />

[rogue_ronin]

Originally Posted by pdurrant

Personally, I'd have

Cover
Title Page
(Possibly Dedication)
Parts
Everything else

I generally read Mobipocket format eBooks. They have a "Go To" menu that's usually populated with links to Start of Book, Table of Contents, etc. So to navigate in the book, I just bring up that menu and choose.

For example, the book I'm reading now "Morality for Beautiful Girls" has the following items on the "Go To" menu:

First Page
Start Reading
Table of Contents
Last Page

So getting to the Table of Contents takes the same time no matter where it is. So there's no point in having it at the front, although this book does do that.

I have a CyBook, so no touch screen. When reading a book it's quite quick to being up the main menu, select to the Go To menu, and then choose a desination from there.

The REB1100 has a GoTo menu, also. (Only 7 items, but still useful.) And I usually automatically populate it with a TOC link, First Page link and a Verso link (info about the book.) In addition, I add Next Chapter, Last Chapter and TOC buttons at each chapter heading. So you can just bounce through the book -- but that's for a touch screen of course, or for some other way of selecting links.

Given that you're looking to jump to the TOC, nothing about the structure I've offered would stop you from populating that GoTo menu exactly as you've described, and getting to it immediately. If you don't have a limit on the number of entries, you could include every chapter and other element too (Preface, About the Author, etc.) The difference only comes when you page manually through the book.

There are two things, I think, that your comments (thankfully) suggest to me.

One is that there is a difference between the format for the reader and the purpose of the XHTML specification that I'm trying to work out. Given a comprehensive, rational spec, anyone could transform it easily (ridiculously, scriptably easily) into any form, order or format that works for them and for their hardware. Slap it into Calibre, you've got ePub -- properly separated, etc. rbmake would love this spec, (you might have to use some regex on it for new-pages, but rbmake itself lets you do that) and smack it right into an RB file. I'm sure that the mobipocket converter would recognize it -- might even be able to generate that TOC automatically, but I've no experience with it. I'm certain that someone expert could do it easily.

It's an archiving spec, essentially, although it's readable by anything that reads HTML. It's hardware neutral. It's easily parseable. It's human readable. It is as simple as possible, without losing information. It accurately represents the structure of a book.

Second, if I do this properly, with meta and structure strictly controlled, CSS can do things like change layout such that you reorder the book (at least I think so; wizards please chime in.) At the very least, the CSS would be able to suppress any undesired pieces of the book, given that they will be properly labeled (ie: div.frontispiece { display: none } ) . Just offer you a custom CSS file -- easy to do -- and every book that you get from this spec will appear as you wish it to.

As a corollary to the above ideas: I like opening books and seeing the stuff before the TOC. Real, physical books I mean. I know that we're not talking about the same thing, and that we're not bound to forms that grow from different media -- but I like the traditions of offering you the mental framework of reading, the experience of it. I'm not a typography nut, nor do I read every detail of the printing history of a book when I open it. But I think that the stuff that opens a book (aside from the modern addition of advertisements) are a reflection of the wisdom of crowds -- generations of people kept the best practices and added new ones when they thought of them. The structure of a book is integral to the way it works, and it works in more ways than reading the stories, and I'd like to support that if I can.

So this is a long way of saying that we can both have what we want from this; but the archival nature of the spec means (to me) that the structure of books must be reflected in the structure of the spec. Traditionally, Prefaces appear before TOCs -- but TOCs usually make reference to them, which is great in the new world of links.

When I finish this, I'll convert A Princess of Mars into it; take a look at it (in your browser, even) and I think you'll like the functionality, and hopefully I'll even make a CSS that adds beauty to it. We'll see.

Thanks for provoking me,

m a r