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

Hey Hadrien,


Thanks for the quick reply. Dave's covered the top points, but I'll say a quick bit about the ServiceWorker/caching stuff: it's a demo. :)

How the future browser/reader things implement the details of this approach will (in the end) be entirely up to them. This SW-based approach was just the Simplest Thing That Could Possibly Work (or that was my intent...). It doesn't work everywhere. It will hit cache limitations. Etc. It would also be quite doable via a Web Extension (which have fewer limitations) but those are much harder to demo. :) There's still much to explore.

The Moby-Dick book (as you found) does have metadata in the form of human-readable RDFa-wrapped machine-friendly content.

The The Theory of Heat Radiation book came in while I was coding the pub-bar component, and I didn't do a second pass on it. However, it already has a title and a language. Certainly providing more metadata could make the experience better. As we work to define what metadata we might require, much of it seems human-friendly, so putting it in the markup seemed as good a place as any. :)

Thanks again for the feedback, Hadrien!
Benjamin

--

http://bigbluehat.com/

http://linkedin.com/in/benjaminyoung

________________________________
From: Dave Cramer <dauwhe@gmail.com>
Sent: Wednesday, August 16, 2017 4:19:20 PM
To: Hadrien Gardeur
Cc: W3C Publishing Working Group
Subject: Re: Proposal: Using HTML's nav element as manifest

On Wed, Aug 16, 2017 at 3:39 PM, Hadrien Gardeur <hadrien.gardeur@feedbooks.com<mailto:hadrien.gardeur@feedbooks.com>> wrote:
Hello Dave,


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

It's easy enough to change the visual display of certain list items, or an entire nav element. But I think it's a useful default for everything to appear.

  *   point to the same resource multiple times (for example using fragments to specific locations in a resource)

This is not a problem. We can just say that the "spine" is the unique resources; a TOC can refer to them as many times as needed

  *   point to resources in an order that's not the reading order

I'd be interested to see examples of this; in any case this sounds potentially confusing for the reader.


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


There are tradeoffs to be made, of course.  I feel this proposal makes the vast majority of potential use cases much simpler.

Regards,

Dave