W3C home > Mailing lists > Public > public-publ-wg@w3.org > February 2018

Re: Pursuing the wrong goal? (was Re: A followup/writeup on our Monday discussions (was Re: Continuing discussion on Polyfills))

From: Hadrien Gardeur <hadrien.gardeur@feedbooks.com>
Date: Sat, 10 Feb 2018 13:19:57 +0100
Message-ID: <CA+KS-13_Ut5vVARysQUMSObrytNiX44OOXagy6BJo6DAV3Jvaw@mail.gmail.com>
To: Matt Garrish <matt.garrish@gmail.com>
Cc: Ric Wright <rkwright@geofx.com>, "Ruffilo, Nick" <Nick.Ruffilo@ingramcontent.com>, Dave Cramer <dauwhe@gmail.com>, Leonard Rosenthol <lrosenth@adobe.com>, Daniel Glazman <daniel.glazman@disruptive-innovations.com>, W3C Publishing Working Group <public-publ-wg@w3.org>
Well, once again on the Readium side we've already implemented a manifest
as a "better OPF" and this has been a very successful strategy so far.
The community likes it so much that people who were originally opposed to
this approach are now backporting manifest support to Readium-1, while
other apps (EPUB.js for instance) are adopting the manifest as a key
component of their design.

Having everything in the manifest has helped us with several optimizations
as well, such as preloading assets in cache or pre-rendering adjacent
resources. This results in a better user experience overall.
We couldn't do that nearly as fast if we had to figure out adjacent
resources by parsing the current resource first (to search for prev/next
links). We haven't worked much on FXL yet, but for spreads having
everything in a single manifest will be an absolutely must have, I don't
see how it could work well otherwise (or how you could provide FXL and
spread specific properties in HTML).

I'm more open to the idea of the table of contents not being in the
manifest (it's less important to have it immediately and easily), but
having the reading order in there is IMO a must have.

Received on Saturday, 10 February 2018 12:20:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:52:21 UTC