Manifest

[dauwhe]

Having a list of all files (not just spine items) in a publication is useful when using a service worker to cache book contents.

[frivoal]

On the one hand, yes. On the other hand, it is tedious to maintain, and error prone as that tends to be a duplicate of information already found in the document. On the third hand, HTML is pretty good at hyperlinks, so should we have such a list, it can easily be made part of the index.html.

How about something like this:

• Links inside in index.html are part of the spine and of the toc
• links inside in index.html that have the hidden attribute are part of the spine but not the toc
• links inside in index.html and inside as well are implicitly to rel="preload", unless explicitely marked rel="no-preload"
• Other links in index.html can be marked as rel="preload"
• When offlining, all rel="preload" (implicit or explicit) links must be we included in the archive, including dependent resources and recursively following hyperlinks
• rel="preload no-recurse" means that when offlining, links must be we included in the archive, including dependent resources BUT NOT recursively following hyperlinks.

preload might be the wrong kind of rel, and maybe we should go with role instead of rel, and my syntax may be a bit wacky, but you get the idea.

This gives you default semantics of what is included without duplicating what's already there in the collection of documents, the ability to express additional inclusion of files, and if you want to for performance reasons, you can still duplicate all that in the index.html for performance reasons if you wish to.

[therealglazou]

The file manifest we have in EPUB is one of the most painful things to maintain in a EPUB production environment. If a BlueGriffon user opens a *.epub zip file to edit it and manually inserts, moves or removes a file (for instance through command line), the whole package is messed up. A zip file is already a manifest in itself, and I'm not sure we need the mimetypes anyway.