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

[Admin] Re: Proposal: Using HTML's nav element as manifest

From: Ivan Herman <ivan@w3.org>
Date: Wed, 16 Aug 2017 22:35:27 +0200
Cc: Hadrien Gardeur <hadrien.gardeur@feedbooks.com>, W3C Publishing Working Group <public-publ-wg@w3.org>
Message-Id: <0CE0CFDA-FE76-471F-A6EC-1C0988516296@w3.org>
To: Dave Cramer <dauwhe@gmail.com>
Purely admin comment: This proposal is closely related to one of the open issues on github (sorry, it is difficult for me right now to find the exact reference). Could we, please, pretty please, have this discussion on one place, ie, either as part of that issue, or, if you prefer, as part of a new,albeit closely related issue? We will create a mess for ourselves...



Ivan Herman
Tel:+31 641044153

(Written on mobile, sorry for brevity and misspellings...)

> On 16 Aug 2017, at 22:19, Dave Cramer <dauwhe@gmail.com> wrote:
>> On Wed, Aug 16, 2017 at 3:39 PM, Hadrien Gardeur <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
Received on Wednesday, 16 August 2017 20:35:37 UTC

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