W3C home > Mailing lists > Public > public-publ-wg@w3.org > August 2017

Re: Proposal: Using HTML's nav element as manifest

From: Hadrien Gardeur <hadrien.gardeur@feedbooks.com>
Date: Wed, 16 Aug 2017 21:39:19 +0200
Message-ID: <CA+KS-11JXXzAMEpsdNGxOg0wTVm9Krsnt4tNWpNqqs=MPC=Rvg@mail.gmail.com>
To: Dave Cramer <dauwhe@gmail.com>
Cc: W3C Publishing Working Group <public-publ-wg@w3.org>
Hello Dave,

I haven't looked at everything in details yet, but here's some early
feedback.

1. Human-focused. User agents need a list of primary resources and their
> default ordering, but so do actual users. Most web publications would
> benefit from a human-readable table of contents. TOCs are crucial for
> accessibility.
>
> 2. Simplicity. Given the broad need for a TOC, using that as manifest is a
> straightforward way to avoid duplication (as in EPUB's
> nav/manifest/spine/ncx). And we've discovered a huge benefit, as we don't
> need a list of secondary resources to facilitate offline caching via
> service workers (see the demo books)!
>

You're conflating two different things here:

   - list of primary resources in reading order (spine in EPUB)
   - table of contents (which is navigation)

They can be the same thing for a novel like Moby Dick but they can also be
vastly different, for instance a ToC could:

   - only point to some, not all primary resources
   - point to the same resource multiple times (for example using fragments
   to specific locations in a resource)
   - point to resources in an order that's not the reading order

Saying that a list of primary resources duplicates a ToC (or any other
navigation) is therefore incorrect in the general case.

The "huge benefit" for caching secondary resources comes at a very
expensive cost:

   - the whole book is rendered in the background, which can be slow (CPU
   and network intensive) and takes a lot of resources (CPU, RAM and storage)
   - if you leave the first page in the middle of the process, this could
   potentially interrupt caching
   - this strategy won't work with platforms that do not support Service
   Workers (for instance on iOS)
   - without a list of secondary resources, there's no easy way to know
   what's part of the publication or not and you can't optimize
   preloading/prefetching (by only requesting the most important resources,
   such as fonts/CSS/JS)
   - there are many issues with serving video/audio from a SW Cache Storage
   (byte ranges, the cache could be way too small) which can't be easily
   solved since you don't have a list of such resources

Regarding metadata, I don't see any real proposal regarding this HTML
proposal. How do you expect metadata to be expressed?
The Moby Dick example includes metadata, but not there's nothing for The
Theory of Heat Radiation.

Hadrien
Received on Wednesday, 16 August 2017 19:40:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:49:06 UTC