Navigating a web publication

[dauwhe]

From @dauwhe on June 27, 2017 18:0

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?

Copied from original issue: w3c/publ-wg#14

[dauwhe]

From @iherman on June 28, 2017 9:48

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 <nav> element sounds like a good idea, although I do not believe there is any standard browser behaviour to handle that (alas!).

[dauwhe]

From @mattgarrish on June 28, 2017 11:54

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
[2] https://lists.w3.org/Archives/Public/public-html/2011Feb/att-0481/issue-118-decision.html

[dauwhe]

Probably not require: we do not want to complicate life for those who want to publish a single HTML document

The single-HTML-document case is interesting, as it also avoids questions of reading order. So I can see making nav optional in that case. But what if there are multiple content documents? Should nav still be required? Is there an alternative that would be easy to author and useful to humans?

[dauwhe]

From @TzviyaSiegman on June 28, 2017 14:3

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.
Most scholarly journal reading platforms provide navigation on the platform. That is, there is something (headings) that feeds into a system that generates a TOC, very much like EPUB nav and today's reading systems. Here is a screen capture from Wiley Online Library with the article navigation on the right. It is generated from the level 1 and 2 heads in the HTML.

[dauwhe]

From @iherman on June 28, 2017 14:9

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...)

[dauwhe]

From @HadrienGardeur on July 2, 2017 20:16

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 <link> or the Link header in HTTP. I don't think that we should require all resources to include such a link.

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.

[dauwhe]

From @WSchindler on July 3, 2017 14:36

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.

[dauwhe]

From @HadrienGardeur on July 3, 2017 14:41

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...)

[dauwhe]

From @WSchindler on July 3, 2017 15:0

@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?

[dauwhe]

From @HadrienGardeur on July 3, 2017 15:7

@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).

[dauwhe]

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?

[dauwhe]

From @lrosenthol on July 3, 2017 22:2

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 notifications@github.com
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
w3c/publ-wg#14 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AE1vNZHKpr49O_5pR1lrbTbDWZvGuWi8ks5sKWCMgaJpZM4OG-7Q
.

[dauwhe]

From @HadrienGardeur on July 3, 2017 22:27

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?

@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.

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.

@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.
Instead we treat media overlays as a separate service that can be discovered in the manifest (URI template + rel value + media type).

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.

[dauwhe]

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.

Does this mean that any sort of navigation aid for a web publication is optional, and entirely at the discretion of the content author?

[GarthConboy]

We may want to come up with a different requirement (for navigation document of some sort) at one of our various levels: WP, PWP, EPUB4 -- likely driven by A11Y requirements.

[HadrienGardeur]

Does this mean that any sort of navigation aid for a web publication is optional, and entirely at the discretion of the content author?

If we consider that single resource publications are within the scope of our work, I think so.

We can't force navigation when there's none, the same way that we can't force random HTML pages on the Web to start using ISBNs/UUIDs with a timestamp as their unique identifier.

[avneeshsingh]

Without going into details of technology, I would say that user agent or reading system shuld be able to reconstruct the hierarchy of the publication spread across multiple files. In EPUB there were no constraints on use of h1 to h6 as per the hierarchy of the sections (spread over multiple files). So, Nav Doc was important.
So, in case of WP/PWP, if a simple algorithm can easily reconstruct the exact hierarchy from the structure of the publication then Nav Doc may not be required, else we will need a navigation document.

[iherman]

Propose closure: I believe it is obsoleted by the current draft's infoset content (plus some discussions around affordances.

[iherman]

Closing per https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-03-12-minutes.html#resolution2