[nav] list items not following spine order
Daniel Weck
<!-- KEITH: I thought we could define `nav`s that didn't
exactly match the `spine` order? -->
http://epub-revision.googlecode.com/svn/trunk/build/spec/epub30-contentdocs.html#confreq-nav-a
Are you also concerned about list items having to match the order of
targeted elements within individual content documents ? Or are you
just concerned about the spine order ?
Thank you for clarifying this.
Cheers, Daniel
Lee Passey
1. It was my understanding that the new XHTML 'nav' format was to replace the
.ncx format which replaced the now deprecated <tours> element. The purpose of
the <spine> element is to provide the "primary reading order of the
publication"; i.e. if there were no other navigation specified a User Agent
should present the content in "spine order." The purpose of the <tours>
element was to provide an alternative reading orders. By the transitive
property I conclude that a.) multiple <nav> elements must be permitted, and
b.) no specific <nav> element need follow the spine order. If "The order of li
elements...must also conform to the order of Content Documents in the
Publication spine", as is currently specified, then perhaps the <tours>
element needs to be de-deprecated.
2. It is my understanding that the Epub Navigation document was converted to
XHMTL format primarily so it could be included as part of the primary document
(i.e. part of the <spine>). In my experience, unordered lists <ul> tend to be
more appropriate for display than ordered lists <ol>. I propose the Epub
Navigation Document specification be amended to allow either ordered or
unordered lists as the basis for navigation.
Daniel Weck
Currently, we describe the specifics for some common types of
navigation structures, namely: the "toc" (unique and mandatory), "page-
list" (unique and optional) and "landmarks" (unique and optional). Do
you agree that the specification should enforce strict ordering rules
for the "toc" and "page-list" types ? (all other epub:types would be
allowed to not match the spine or document orders)
Regards, Dan
On 24 Mar 2011, at 17:50, Keith Fahlgren wrote:
> On Wed, Mar 23, 2011 at 3:05 PM, Daniel Weck <danie...@gmail.com>
> wrote:
>> Are you also concerned about list items having to match the order of
>> targeted elements within individual content documents ? Or are you
>> just
>> concerned about the spine order ?
>
> Like Lee, I believed that we could define machine-readable table of
> contents that did not exactly match the linear reading order specified
> by the OPF spine.
>
> Keith
Keith Fahlgren
> Do you agree that the
> specification should enforce strict ordering rules for the "toc" and
> "page-list" types ?
No? I guess I don't understand what value that sort of restriction
would bring to the specification. Perhaps DAISY members have a better
understanding of the tradeoffs (from the history of NCX) and could
clarify?
Thanks,
Keith
Daniel Weck
ordering assumption to synchronize the selection in the document pane
with the various navigation views (toc, pages, etc.). The algorithm
needs to run fast over large data sets, thus why the ordering pre-
requisite is useful. This is however easy to fix (just thought I'd
answer with a concrete technical use-case).
I am more concerned about the reader's expectations regarding the way
information is organized within the publication: aren't "mangled" TOCs
or page lists sub-optimal from a cognitive standpoint ? Do you see any
value in allowing shuffled TOCs and page-lists ? Are there types of
documents that would require this flexibility in the markup model ?
Cheers, Dan
Peter Sorotokin
For both page list and toc you need to know where you are (on which page and
in which section of the book) based on you location. Ordering rules provide
this mapping. I do not understand how that mapping could happen if toc and
page list are not ordered.
Peter
Keith Fahlgren
current document (rather than an idea of "order"), but if you both
feel that the ordering constraint is helpful let's keep it. I can come
up with contrived cases where it would make sense, but I'm not hearing
any pressure on that from content creators.
Thanks,
Keith
Lee Passey
> Keith,
>
> For both page list and toc you need to know where you are (on which page and
> in which section of the book) based on you location. Ordering rules provide
> this mapping. I do not understand how that mapping could happen if toc and
> page list are not ordered.
Of course, lists need to be ordered (as opposed to ordered lists). The
question is whether the lists need to be ordered in the same order as the
<spine> entries.
Most books have a copyright page, and a metadata page (for Library of Congress
data). I can easily see a publisher wanting to put these pages at the
beginning of the spine (so they will be seen first when moving sequentially
through the publication) but references to them being placed last in the Table
of Contents (or being omitted from the TOC altogether).
I have a harder time coming up with a reason that a "page-list" would be out
of sync with the spine, but I have a hard time coming up with a use for a
"page-list" <nav> element at all (unless you're trying to create an Epub that
looks and acts like a PDF document - in which case you'd probably just want to
create a PDF in the first place). So I can't see any reason not to impose the
ordering restriction on the optional "page-list" <nav> element.
Brady Duga
Most books have a copyright page, and a metadata page (for Library of Congress
data). I can easily see a publisher wanting to put these pages at the
beginning of the spine (so they will be seen first when moving sequentially
through the publication) but references to them being placed last in the Table
of Contents (or being omitted from the TOC altogether).
I have a harder time coming up with a reason that a "page-list" would be out
of sync with the spine, but I have a hard time coming up with a use for a
"page-list" <nav> element at all (unless you're trying to create an Epub that
looks and acts like a PDF document - in which case you'd probably just want to
create a PDF in the first place). So I can't see any reason not to impose the
ordering restriction on the optional "page-list" <nav> element.
George Kerscher
Hi folks,
In education where there will be print books and EPUB 3 used, the ability to go to a particular print page will be a wonderful feature. Perhaps in the future when there are only EPUBs this would not be needed. For now, I think this is an important use case.
Best
George
Frank Rubino
Brady Duga
Matt Garrish
Am I alone in getting these message threads all jumbled out of order since we changed email lists? I received this email about ten minutes before the one you were replying to and I still haven’t a clue what Lee wrote except what I’ve seen excerpted. I also got a couple of bursts of really old emails being resent earlier today.
Matt
George Kerscher
Matt, you are not alone.
Best
George
Matt Garrish
workaround to keep up on these discussions, as I see a number of
messages in it from today that haven't come through to my email.
Matt
Lee Passey
[snip]
> I believe this is used for mapping the page numbers from a specific
> print edition of a book to the ePub. So, you could go to print page 73
> in your ePub. I suppose it might be used in classroom settings. Several
> reading systems support similar features today, though I remain
> unconvinced that they are all that useful in practice.
Okay, given this use case can you explain why it would require that the
list of page number be synchronized to the spine?
I've done some work ePubizing the Harvard classics (where I got one of
the translations of "Father Goriot"). Every work in the set is preceded
by one or more introductory segments. Suppose that for my purposes I
want to move the introductory material to the end of the spine, but I
want to maintain the print page number mapping. Should my page map for
George Sand's _The Devil's_Pool (which starts at page 281) be:
<ul>
<li><a href="Devils_pool_ch01.html#pg001">281</a></li>
<li><a href="Devils_pool_ch01.html#pg002">282</a></li>
...
<li><a href="Devils_pool_intro1.html#pg001">269</a></li>
<li><a href="Devils_pool_intro1.html#pg002">270</a></li>
...
<ul>
or should I maintain the natural page order which will be out of sync
with the spine? If this is just a pre-mapping of anchors which already
exist in the publication, to some value external to the publication,
does order matter at all? The User Agent should be able to order the
inner text of each of the <li>s in whatever makes sense.
I don't think the requirement that the page numbers should be listed in
the same order as the spine does any harm, but I don't think it does any
good either, and my basic inclination is that we shouldn't make
requirements just for the sake of requirements. I wouldn't support the
requirement unless someone can come up with a use case which /requires/ it.
Cheers,
Lee
Peter Sorotokin
books chapters do not start on the page boundary. The first page in the
chapter may actually fall in the middle of the chapter, or even worse, a
chapter may be so short that it does not occupy a single page in the printed
edition. In these cases, a consistent chapter ordering is required in
addition to the page list. If spine cannot serve that purpose, something
else has to be invented (and we have to ask ourselves if additional
complexity is justified). Don't dismiss this case as artificial: I have
learned about these cases the hard way (bugs).
One usability problem with your example is that page break points are often
used for linear navigation in the book (e.g. I am on page 281 out of 522).
While any page names can be assigned, it is very confusing to the user if
they are not ordered in some predictable way.
Peter
Lee Passey
> The problem is conceptual, rather then purely technical. In some printed
> books chapters do not start on the page boundary. The first page in the
> chapter may actually fall in the middle of the chapter, or even worse, a
> chapter may be so short that it does not occupy a single page in the printed
> edition.
Okay, I'm with you so far.
> In these cases, a consistent chapter ordering is required in
> addition to the page list.
Why? The spine represents the primary reading order of the document, which may
not contain chapters at all. If anything, the page list is the outlier here,
not the spine. The spine is mandatory, page lists optional. A page list /may/
be synced to the spine, perhaps it /should/ be synced to the spine, but why
/must/ it be synced to the spine?
> If spine cannot serve that purpose, something
> else has to be invented (and we have to ask ourselves if additional
> complexity is justified). Don't dismiss this case as artificial: I have
> learned about these cases the hard way (bugs).
>
> One usability problem with your example is that page break points are often
> used for linear navigation in the book (e.g. I am on page 281 out of 522).
> While any page names can be assigned, it is very confusing to the user if
> they are not ordered in some predictable way.
If I understand correctly, what you are proposing here is a new and different
use case. In this case the page list is not really a "page" list, but a
"milestone" list which can be used by a User Agent to display the progression
through a publication, obviating the need for the User Agent to compute the
progression based on the computed size, like most User Agents do today.
My first reaction to this new use case is that it is a misnomer to categorize
it as a page list; the items have no significance outside the publication
(they may but need not refer to any canonical page number) and they do not
refer to any particular "page" as the page size (and therefore number) will
vary from User Agent to User Agent. In order to satisfy the stated use case it
seems that this "milestone" list must indeed match the spine order, there must
be but one in the publication, and the milestones must appear at substantially
equal intervals throughout the publication (2k segments at the beginning of
the publication and 10k segments at the end will also violate user's
expectations of a progression indicator).
I think this new (to me at any rate) use case is worthwhile, but can
conceivably be incompatible with the earlier use case of mapping canonical
page numbers to text points. A few years ago I worked on a project involving
_Emma_ by Jane Austen. In that case the source files contained two sets of
page numbers each set representing different print editions. In that case it
seems to me it would be appropriate to have /two/ "page-list" <nav> elements,
one for each print edition (currently prohibited by the specification).
Maybe it would be most appropriate to have two different kinds of <nav>
elements, one to represent each of these use cases, and to permit epub:type to
be combined. For sake of discussion, let's call these list types "page-map"
and "milestones". In the case the list is constructed to satisfy both the
requirements of progression display and canonical page numbers the list could
be:
<nav epub:type="page-map milestones">
If the list is only appropriately used for one or the other of these functions
then a single attribute value could be used, and if both lists are appropriate
by incompatible then two lists, one of each type, could be specified.
The multi-value option could also be extended to other types of <nav> lists.
For example, in "Old Goriot" there are no chapter divisions, so the required
"toc" <nav> list (should the existence of a "toc" really be required?) would
basically be:
<nav epub:type="toc" id="toc">
<h1>Table of contents</h1>
<ul>
<li><a href="Goriot_part1.html">Old Goriot</a></li>
</ul>
</nav>
Maybe in this case it would be best to use the page map as the Table of
Contents as well, e.g.:
<nav epub:type="toc page-map" id="navigation">
<h1>Table of contents</h1>
<ul>
<li><a href="Goriot_part1#pg001.html">Page 1</a></li>
<li><a href="Goriot_part1#pg002.html">Page 2</a></li>
<li><a href="Goriot_part1#pg003.html">Page 3</a></li>
...
</ul>
</nav>
In my version of "Old Goriot" I haven't tracked page numbers, but I have
sequentially numbered paragraphs, so maybe "page-map" is also misleading;
maybe just "map" instead? And if one list can satisfy the needs of progression
display, canonical mapping, and table of contents is there any reason not to
use a single list, e.g. epub:type="toc milestones map"?
Just food for thought...
Cheers,
Lee
Bill McCoy
Peter Sorotokin
On 3/25/11 9:45 AM, "Lee Passey" <l...@novomail.net> wrote:
> On Thu, March 24, 2011 11:11 pm, Peter Sorotokin wrote:
>
>> The problem is conceptual, rather then purely technical. In some printed
>> books chapters do not start on the page boundary. The first page in the
>> chapter may actually fall in the middle of the chapter, or even worse, a
>> chapter may be so short that it does not occupy a single page in the printed
>> edition.
>
> Okay, I'm with you so far.
>
>> In these cases, a consistent chapter ordering is required in
>> addition to the page list.
>
> Why? The spine represents the primary reading order of the document, which may
> not contain chapters at all. If anything, the page list is the outlier here,
> not the spine. The spine is mandatory, page lists optional. A page list /may/
> be synced to the spine, perhaps it /should/ be synced to the spine, but why
> /must/ it be synced to the spine?
>
Because for each place in the book I need to be able to say which page it is
on. If a chapter does not contain any page breaks and thus is not listed in
the page list, how do I know which page a location in this chapter is on?
In other words, ordering makes page mapping bidirectional and I do not want
to lose that feature.
>> If spine cannot serve that purpose, something
>> else has to be invented (and we have to ask ourselves if additional
>> complexity is justified). Don't dismiss this case as artificial: I have
>> learned about these cases the hard way (bugs).
>>
>> One usability problem with your example is that page break points are often
>> used for linear navigation in the book (e.g. I am on page 281 out of 522).
>> While any page names can be assigned, it is very confusing to the user if
>> they are not ordered in some predictable way.
>
> If I understand correctly, what you are proposing here is a new and different
> use case. In this case the page list is not really a "page" list, but a
> "milestone" list which can be used by a User Agent to display the progression
> through a publication, obviating the need for the User Agent to compute the
> progression based on the computed size, like most User Agents do today.
All Reading Systems based on Adobe SDK give you progression indicator based
on the page map. Computed size is used only if page map is not found. Linear
navigation is what page numbers are used today in printed books, so I do not
see how it is a new requirement.
Note that page number and page "name" or "label" are different things. In
Digital Editions we display both if they differ.
[snip]
Peter
>
> Cheers,
> Lee
>
>
>
Daniel Weck
Given that the numerous possibilities for nav-related epub:types, as
an author and as an implementor I feel pretty satisfied with EPUB3
recommending and specifying the use of "toc", "page-list" and
"landmarks" for the commonly-understood purpose they fulfill. This
doesn't prevent me from achieving more out-of-the-box use-cases with
other navs/epub:types, but from an interoperability standpoint I feel
that the nav specification strikes the right balance here.
I have come across confusing reading systems where the difference
between dynamic pagination and authored pages (print-inherited or not)
wasn't clear, but that's more an implementation issue than a standards-
related problem.
The case for print-inherited pages is pretty clear, judging by
comments in this email thread. As for the spine/document ordering, I
fail to see why a MUST conformance requirement is a problem for "page-
list" and "toc" (only those), and as we've seen in previous emails,
ordering has both technical justifications (for programmers) and
cognitive benefits (for users).
Dan
Daniel Weck
list and toc navigation.
References:
http://epub-revision.googlecode.com/svn/trunk/build/spec/epub30-contentdocs.html#sec-xhtml-nav-def-types-toc
http://epub-revision.googlecode.com/svn/trunk/build/spec/epub30-contentdocs.html#sec-xhtml-nav-def-types-pagelist
http://code.google.com/p/epub-revision/issues/detail?id=111
On 25 Mar 2011, at 20:13, Daniel Weck wrote:
> Hi Lee. Thank you for illustrating your point(s).
> Given that the numerous possibilities for nav-related epub:types, as
> an author and as an implementor I feel pretty satisfied with EPUB3
> recommending and specifying the use of "toc", "page-list" and
> "landmarks" for the commonly-understood purpose they fulfill. This
> doesn't prevent me from achieving more out-of-the-box use-cases with
> other navs/epub:types, but from an interoperability standpoint I
> feel that the nav specification strikes the right balance here.
>
> I have come across confusing reading systems where the difference
> between dynamic pagination and authored pages (print-inherited or
> not) wasn't clear, but that's more an implementation issue than a
> standards-related problem.
>
> The case for print-inherited pages is pretty clear, judging by
> comments in this email thread. As for the spine/document ordering, I
> fail to see why a MUST conformance requirement is a problem for
> "page-list" and "toc" (only those), and as we've seen in previous
Daniel Weck
danie...@gmail.com
Daniel Weck
On 24 Mar 2011, at 17:15, Lee Passey wrote:
> In my experience, unordered lists <ul> tend to be
> more appropriate for display than ordered lists <ol>. I propose the
> Epub
> Navigation Document specification be amended to allow either ordered
> or
> unordered lists as the basis for navigation.
Hi Lee, with all due respect, I am in disagreement with your conclusion.
The format of the EPUB navigation document should be kept as simple as
possible, and I don't see how unordered lists add value. With "ol",
the author's intent is non-ambiguous. CSS-capable reading systems can
render numbered list item headings if so-specified by content
creators. The navigation display in the primary user-interface
(provided by the reading system) is subject to the "nav" document
order. I don't see a need for "ul" at all. Can you please suggest some
use-cases ?
Thanks, Daniel
Lee Passey
First let me say that I am a firm believer in "graceful degradation". I
am fairly certain that there is not a single Android application that is
completely ePub compliant; therefore, it is important to me to have
ePubs which degrade gracefully when viewed in these sub-par applications.
This is one of the reasons I support so strongly XHTML toc documents; if
I include one in the spine I'm highly likely to get a Table of Contents
even in viewers that /aren't/ Adobe Digital Editions.
Let's assume a User Agent that hasn't figured out how to do external
style sheets (and there are a lot of them). Using ordered lists, the
Table of Contents for George Sand's _The Devil's Pool_ would look like:
1. Biographical Note
2. Criticisms and Interpretations - by Benjamin W. Wells
3. Criticisms and Interpretations - by Matthew Arnold
4. Author's Preface
5. The Author to the Reader
6. Chapter I - The Tillage of the Soil
7. Chapter II - Father Maurice
8. Chapter III - Germain, the Skilled Husbandman
etc.
You will note two serious disconnects: the item number doesn't match the
chapter number, and the item number uses Arabic numerals, whereas the
chapter headings use Roman numerals. You could certainly make apologies
for this appearance ("If you are seeing Arabic numbers in the Table of
Contents it is probably because your User Agent has not fully
implemented the ePub Specifications") but I'd rather not have to, and
simply changing this from an ordered list to an unordered list would go
a long ways towards making this look better. In fact, given the
"generic" nature of the unordered list, I think that if you had to
decide on only one list element it probably ought to be the unordered list.
You are correct in saying that "CSS-capable" reading systems can
override the standard markup, essentially saying, "you know that ordered
list I told you about? I lied. It's really an unordered list." But as of
right now I would venture to say that CSS-capable User Agents are the
exception, not the norm. And even if they are the norm, why would you
want to not support the CSS-incapable User Agents if you could?
Another good (and more modern) example is the Table of Contents for
Michael Pollan's book, _The Omnivore's Dilemma_ (you can look up the
book on Amazon, and then "Look Inside" to see the Table of Contents).
How would that best be marked up if you had to rely on native HTML
without the benefit of CSS?
What I would like to see is a mechanism I can use to add
machine-readable tags to an already prepared TOC rather than forcing the
TOC to use a somewhat artificial markup that can only be made to look
acceptable via the use of CSS.
Daniel Weck
fantasai
>
> You are correct in saying that "CSS-capable" reading systems can override the standard markup, essentially saying, "you know
> that ordered list I told you about? I lied. It's really an unordered list." But as of right now I would venture to say that
> CSS-capable User Agents are the exception, not the norm. And even if they are the norm, why would you want to not support the
> CSS-incapable User Agents if you could?
This is not a lie. The list is *ordered*. If you reordered
the list it would be *wrong*. Therefore the correct markup
is <ol>.
Whether the <ol> should have numbers is a stylistic issue.
But the tag is for an Ordered List, not a Numbered List,
and therefore <ol> is the only correct answer for a TOC.
Since the concern is stylistic, I suggest that the UA stylesheet
for a TOC include a rule that makes such ULs list-style: none
by default. A non-CSS UA could similarly determine not to display
numbers for TOC <ol>s.
~fantasai
Lee Passey
[snip]
> This is not a lie. The list is *ordered*. If you reordered
> the list it would be *wrong*. Therefore the correct markup
> is <ol>.
>
> Whether the <ol> should have numbers is a stylistic issue.
> But the tag is for an Ordered List, not a Numbered List,
> and therefore <ol> is the only correct answer for a TOC.
You raise a good point; in fact, the definitions for <ol> and <ul> have
changed between the established HTML 4 and the draft HTML 5. According to the
HTML 4 specification, "Ordered and unordered lists are rendered in an
identical manner except that visual user agents number ordered list items.
User agents may present those numbers in a variety of ways. Unordered list
items are not numbered."
However the HTML 5 draft states, "The ol element represents a list of items,
where the items have been intentionally ordered, such that changing the order
would change the meaning of the document.... The ul element represents a list
of items, where the order of the items is not important � that is, where
changing the order would not materially change the meaning of the document."
HTML 4 does seem to focus on presentation; <ol> lists are explicitly numbered
lists, while <ul> lists are unnumbered. If the HTML 5 draft is adopted,
presumably it will be allowable for User Agents to arbitrarily reorder <ul>
lists.
> Since the concern is stylistic, I suggest that the UA stylesheet
> for a TOC include a rule that makes such ULs list-style: none
> by default. A non-CSS UA could similarly determine not to display
> numbers for TOC <ol>s.
I can understand, and sympathize, with the desire to mark up lists according
to their properties and not their presentation. But the sticking point for me
is, what will these lists look like in User Agents which do not support style
sheets? I suspect the default presentation for HTML 5 UAs will continue to be
that <ol>s are numbered lists while <ul>s are unnumbered. I also suspect that
there will be absolutely /no/ User Agents which will take it upon themselves
to reorder <ul>s. I further suspect that the cost to developers of
implementing a User Agent which can recognize /either/ a <ol> or a <ul> as a
toc nav list approaches zero, if only it is made clear to them that they
should.
In this instance, as in others, I think that ideological purity should yield
to practicality and inclusiveness.
Cheers,
Lee
Peter Sorotokin
I totally agree. This is semantical, not presentational issue.fantasai wrote:
Peter
>
> You are correct in saying that "CSS-capable" reading systems can override the standard markup, essentially saying, "you know
> that ordered list I told you about? I lied. It's really an unordered list." But as of right now I would venture to say that
> CSS-capable User Agents are the exception, not the norm. And even if they are the norm, why would you want to not support the
> CSS-incapable User Agents if you could?
the list it would be *wrong*. Therefore the correct markup
is <ol>.
Whether the <ol> should have numbers is a stylistic issue.
But the tag is for an Ordered List, not a Numbered List,
and therefore <ol> is the only correct answer for a TOC.
for a TOC include a rule that makes such ULs list-style: none
by default. A non-CSS UA could similarly determine not to display
numbers for TOC <ol>s.
Daniel Weck
resolution on the working group conference call), and let us know if
this works for you:
Regards, Daniel
Daniel Weck
danie...@gmail.com
Lee Passey
> Hi Lee, please review the improved specification prose (following the
> resolution on the working group conference call), and let us know if
> this works for you:
>
> http://epub-revision.googlecode.com/svn/trunk/build/spec/epub30-contentdocs.html#confreq-nav-ol-style
Not really. You see, the issue arises when a User Agent is unable (or
unwilling) to use CSS, so no solution is possible which relies on CSS
for it's implementation. (I say unwilling because some User Agent's,
such as Aldiko and Opera allow the end user to turn off publisher
supplied style-sheets -- and given some of the publisher supplied style
sheets I've seen lately I can understand why that option is desirable).
I don't know of a single User Agent developer, including me, who's going
to go to the trouble of implementing a new HTML parser/renderer which
will support a default list style of "none" for lists, particularly when
that same parser/renderer is going to be required to display lists
according to their well-established presentation in other contexts.
We're going to grab something like WebKit, Gecko, WxWidgets etc, and
just throw the HTML at them and expect them to do the right thing. In
fact, I would be very surprised if anyone other than Adobe will even go
to the effort of checking for the <nav> element when parsing the spine
elements. I'd bet real money that in most cases when the TOC document
appears in the spine it will be passed to the default renderer without
checking to see if special CSS rules need to be applied, which means in
most cases they will be displayed as numbered lists.
Allowing authors to use alternate list styles controlled by CSS only
makes things worse, because when CSS is turned off or is otherwise
unavailable the end user will now get /two/ tables of contents.
I'm having a hard time understanding the resistance to including <ul> as
well as <ol> in the nav list specification. The TOC code is most likely
going to be special code, not just another frame with HTML inside it
(it's likely an HTML parser/renderer will just throw the unrecognized
<nav> element away, as is required). When used for its special purpose,
the nav list isn't going to be parsed or rendered by the HTML engine at
all; it's going to be parsed by a special XML parser which will look for
the nav element specifically, and then build some kind of special
UA-specific frame or window to display the data in its own way. I can't
see the burden of doing:
if ((element.name.equals( "ol" ) || (element.name.equals( "ul" ))
instead of just
if (element.name.equals( "ol" )
in the special TOC parsing code.
Because the TOC parsing system is the special code, I would think the
approach ought to be to start with a system that allows the greatest
flexibility in XHTML rendering, /then/ add the special tags and
attributes necessary for the special processing. Heck, I'd even replace
the <nav> element with <div class="nav"> just to make processing easier.
I would propose the following language in the second bullet item of the
section:
"The optional heading must be followed by a single ol or ul list
element; no other elements are permitted as direct children of the nav
element. This list represents the primary level of content navigation."
Thereafter, just add the words "or ul" after the word "ol" and remove
the word "ordered." Easy to do, easy to implement.
I also fail to see the value of the unidentified, unclassed <span> tag
in the spec, but that's a benign if valueless requirement.
Peter Sorotokin
I do not think anyone invoked hard-to-implement argument. It is semantics
vs. presentation argument. Table of content is by its nature an ordered list
and it should be expressed as such. What you propose is in effect using HTML
as presentational language, where in EPUB3 we are trying to move it to even
more towards semantics. That's just not consistent.
I think that it would be an extremely bad idea for a Reading System to use
default HTML stylesheet (or default HTML rendering for non-CSS systesms) for
the table of contents (and this issue is not the only reason). Perhaps this
should be explicitly called out in the spec. Would that work for you?
Peter
Lee Passey
> Lee,
>
> I do not think anyone invoked hard-to-implement argument. It is semantics
> vs. presentation argument. Table of content is by its nature an ordered list
> and it should be expressed as such. What you propose is in effect using HTML
> as presentational language, where in EPUB3 we are trying to move it to even
> more towards semantics. That's just not consistent.
>
> I think that it would be an extremely bad idea for a Reading System to use
> the table of contents (and this issue is not the only reason). Perhaps this
> should be explicitly called out in the spec. Would that work for you?
Well, no.
I think that what we have here is an honest difference of opinion. I
feel that if you're going to eschew presentation for semantics, you
shouldn't be using XHTML at all, as it has strong presentational
baggage. We might as well go back to using something like NCX which is
purely semantic.
The introduction to this section states, that the EPUB Navigation
document "provides the Author with a mechanism to include a human- and
machine-readable global navigation layer in the Publication, thereby
ensuring increased usability and accessibility for the User." I had
understood that moving from NCX to XHTML was explicitly designed to
provide for a hybrid document, which could be rendered as is by an HTML
software component but processed as well algorithmically. There is some
tension between these two requirements, but I don't believe they are
irreconcilable.
FWIW, I have never encountered a TOC that could not be acceptably
rendered using only the default HTML styling. But whether you and I
agree or disagree on this point I think it's important to note that
there will be any number of end users who will agree or disagree with
either of us, and a number of User Agents which will allow for external
stylesheets to be disabled. What then? Is it the position of the IDPF
that ePub styling should be "my way or the highway?"
Of all the voices I hear on the list, I rarely hear anyone advocating
for the reader.
Markus Gylling
> I think that what we have here is an honest difference of opinion.
Yes, and here's the situation: the working group discussed the issue at yesterdays call, and resolved that staying with <ol> + adding informative prose (a note or somesuch) about default UA styles is what we will be doing for EPUB3. The case can thereby be considered closed; the only event that would make us reconsider/reopen is if substantial new information is presented (and in this thread, it is now quite a while ago that such information appeared).
/markus
fantasai
> Hi Lee, please review the improved specification prose (following the resolution on the working group conference call), and
> let us know if this works for you:
>
> http://epub-revision.googlecode.com/svn/trunk/build/spec/epub30-contentdocs.html#confreq-nav-ol-style
# list-style: none (Reading Systems with no CSS support must not display list item headings
s/headings/numbers/
~fantasai