Navigating a web publication #14
Comments
|
Probably not require: we do not want to complicate life for those who want to publish a single HTML document with all the surrounding goodies as Web Publication (e.g., journal article). Having an optional navigation document (more or less like EPUB3.1 has with the |
|
Agree with not requiring at the web publication level. We can leave that and any continued structuring requirements for epub to define. A single-page document could identify itself as the source of the toc if it's structured and has one, but I expect there will be plenty of documents with no specific outline or only a single heading. Recommending identification with role=doc-toc on the nav might also be wise, but might also be too much detail at this level. HTML4 defined rel=contents for link,[1] but it got dropped for lack of implementation.[2] Identifying the table of contents in every document seems like a cumbersome approach, but maybe linking from the manifest might revive some interest. We no doubt need to give browsers something tangible to do, and implementations using, before the current situation will change. [1] https://www.w3.org/TR/html4/types.html#type-links |
The single-HTML-document case is interesting, as it also avoids questions of reading order. So I can see making |
|
We may want to consider different approaches for single document WPs and multi-document WPs, as @dauwhe notes. We might consider the headaches that have forced reconsideration of the HTML outline algorithm and all the work that goes into ARIA landmarks before assuming that a single HTML document does not require a TOC.
|
|
The interesting point of that example is that there is some sort of a hierarchy here. A full journal (issue) may be considered as a WP, and that means the need for a TOC. But a single journal article is also a WP: as a reader, I am interested in only one article, but I want to see it offline, too, meaning it is also a WP in isolation. That also means that the association of a manifest (or whatever we call it) with the individual sources must be such that "sharing" should be possible. (Is it a use case that does not appear in the UCR document? I guess it is...) |
|
I strongly believe that Web Publications should not require anything other than a manifest. Linking to that manifest, shouldn't even be a requirement. In the case of a single-resource Web Publication, the manifest can be inlined using a script element (like in AMP). For larger Web Publications, some of the constituent resources can point to an external manifest (identified by its own URI) using HTML There's absolutely no requirement when reading a publication for a Navigation Document (or any similar concept) and we should remain consistent with the Web. Such publications already have their own navigations, and we shouldn't force them to adopt something different. |
|
In my understanding, the fundamental difference between a manifest and a navigation document is that the manifest defines the different kinds of resources that make up a WP - content docs, images, audio, video, css files, etc., while the navigation document defines a default reading order, gives a quick overview over the available chunks of content and supports to easily navigate to a specific part. This information could also be used by assistive techniques to allow visually impaired users to skip sections that they are not interested in. Of course, you may argue that any web site of some extent would have a navigation bar and you may use links and fragment identifiers etc. for navigating its contents. Nevertheless, I think that the logical structure of a WP, i.e. the semantic dependencies of its constituent chunks of content, should be visible for the user and be explicitly defined on the basis of a standardized format that could be used by browser vendors and developers of accessibility technology. |
|
In EPUB, the Navigation Document does not define a default reading order. The spine is responsible for that, and it would be included in the manifest. The Navigation Document is responsible for providing alternate ways that the content can be browsed/navigated using a number of lists (table of contents, list of illustrations, page list...) |
|
@HadrienGardeur: would not the Navigation Document give more flexibility in accessing/navigating the contents by offering additional approaches or do you see that sufficiently covered by the spine? |
|
@WSchindler they serve a different purpose, but my point is that the Navigation Document (or its equivalent) shouldn't be a requirement and that there's no reason why we couldn't express all of this in a single manifest (that's already how we handle it in Readium-2, and it's much more consistent and easier to work with for developers). |
What happens when a user navigates to a component of a web publication that doesn't include a link to a manifest (in whatever form)? Are you proposing an alternate way of identifying that the component is part of a web publication? |
|
IMO - If there is no manifest, then it's "stand-alone" (aka a single "page"
publication)
@HadrienGardeur <https://github.com/hadriengardeur>: Yes, we could put
everything into a single manifest - but that will have huge performance
implications as the size of the publication grows. While most books aren't
that large - consider reference works (eg. dictionaries). Or forget about
books and think about documents - a 1000 page document is not uncommon.
And the largest document that was actually consumed by one of our users
last year was over 40000 pages. Trying to load all that into a UA
*before* displaying anything is simply not a good user experience.
…On Mon, Jul 3, 2017 at 5:43 PM, Dave Cramer ***@***.***> wrote:
I strongly believe that Web Publications should not require anything other
than a manifest. Linking to that manifest, shouldn't even be a requirement.
What happens when a user navigates to a component of a web publication
that doesn't include a link to a manifest (in whatever form)? Are you
proposing an alternate way of identifying that the component is part of a
web publication?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#14 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AE1vNZHKpr49O_5pR1lrbTbDWZvGuWi8ks5sKWCMgaJpZM4OG-7Q>
.
|
@dauwhe what's the context? Have you already "discovered" the publication before? If so, I don't see any problem at all. Otherwise, it just means that you won't be able to discover the publication, which is also fine.
@lrosenthol I'm not saying that we should always cram everything in a single manifest. For the current Readium-2 use case where we ingest EPUB, it works fine and is far more consistent than forcing the app developer to manipulate multiple XML files (NCX, OPF) and XHTML (Navigation Document). A key part of our design for the manifest is that it can be easily extended, and we rely extensively on links for that. Media overlays are a good example: while we could parse all media overlays and include them in the manifest, it would be slow and turn the manifest into a much larger resource than it needs to be. Dealing with edge cases like the one that you're describing is always tricky and we need some flexibility/extensibility to make sure that things remain as simple as possible for basic use cases, yet capable of handling very complex ones at the same time. |
|
This issue was moved to w3c/wpub#2 |
Readers need to easily navigate through web publications. Such navigation could be complicated by the reality that many web publications consist of many resources, likely in a defined order. EPUB reading systems typically provide UI to access a (required) table of contents from anywhere in the publication, and further provide simple UI gestures to move from document to document.
Should web publications require a comprehensive navigation document? How can we make it easy for users to get from document to document?
The text was updated successfully, but these errors were encountered: