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