Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Navigation documents: target elements might not be ordered #828

Closed
murata2makoto opened this issue Aug 28, 2016 · 3 comments
Closed

Navigation documents: target elements might not be ordered #828

murata2makoto opened this issue Aug 28, 2016 · 3 comments
Labels
EPUB32 Issues from 3.0.1 resolved in the EPUB 3.2 specification Topic-PackageDoc The issue affects package documents
Milestone

Comments

@murata2makoto
Copy link
Contributor

The order of li elements contained within the toc nav element must match the order of the targeted elements within each targeted EPUB Content Document, and must also follow the order of Content Documents in the Rendition's spine.

I think that this is not completely correct. When two li reference different fragments of different content documents, the two fragments are not ordered.

In my understanding:

When an li element A precedes an li element B, either 1) the target content document of A precedes that of B in the Rendition's spine, or 2) the target content document and that of A are the same content document and the fragment referenced by A precedes that referenced by B.

@mattgarrish
Copy link
Member

Sorry, I don't follow what distinction you're trying to make. There are two orderings that have to be respected: 1) the order of elements within the content document, and 2) the order of content documents in the spine.

When you combine those rules, all of the elements in A (in document order) must occur before all of those in B (in document order) before all of those in C ...

So two fragments across different content documents are not ordered by the first rule, but they are ordered by the second.

@murata2makoto
Copy link
Contributor Author

We have the same understanding. But I don't think that the spec captures your intention.

We have three orderings:

  1. the order of li elements contained within the toc nav element

  2. the order of the targeted elements within each targeted EPUB Content Document,

  3. the order of Content Documents in the Rendition's spine.

Here 1) always exists, 2) is non-existent when the targets are in
different content documents. That's why I don't think 1) matches 2).
But the spec says 1) matches 2).

@mattgarrish
Copy link
Member

mattgarrish commented Aug 28, 2016

I'm not sure I see that being said, but what about simplifying this requirement by breaking apart the MUSTs and tweaking the wording as follows:

The references in the toc nav element MUST be ordered such that they reflect both:

  • the order of the referenced EPUB Content Documents in the spine;
  • the order of the targeted elements within their respective EPUB Content Documents.

@mattgarrish mattgarrish added this to the EPUB 3.1 milestone Aug 28, 2016
@mattgarrish mattgarrish added Topic-PackageDoc The issue affects package documents Status-Proposed Solution A proposed solution has been included in the issue for working group review labels Aug 28, 2016
mattgarrish added a commit that referenced this issue Sep 1, 2016
#755 - change alt-script to alt-rep and clarify language
#761 - make image cmts required when there is a viewport
#773 - update roadmap and add diagram
#778 - clarify package conformance
#780 - generalize backwards compatibility statement
#800 - clarify svg handling for fxl documents
#808 - replace spaces with underscores in rootfile examples
#822 - fix obsolete feature labels/descriptions
#823 - add note about incomplete RS requirements for scrolled-continuous
#824 - add clearer content model for nav elements
#826 - note toc nav is required in intro
#828 - clarify ordering requirements for toc nav references
#829 - note optional use of pagebreak with page-list

adds a link to the informative a11y faq;
patches errata not applied to doi examples;
probably some other minor stuff, too
@mattgarrish mattgarrish removed the Status-Proposed Solution A proposed solution has been included in the issue for working group review label Sep 2, 2016
@mattgarrish mattgarrish added the EPUB32 Issues from 3.0.1 resolved in the EPUB 3.2 specification label Aug 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
EPUB32 Issues from 3.0.1 resolved in the EPUB 3.2 specification Topic-PackageDoc The issue affects package documents
Projects
None yet
Development

No branches or pull requests

2 participants