-
Notifications
You must be signed in to change notification settings - Fork 62
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
Comments
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. |
We have the same understanding. But I don't think that the spec captures your intention. We have three orderings:
Here 1) always exists, 2) is non-existent when the targets are in |
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:
|
#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
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.
The text was updated successfully, but these errors were encountered: