- From: Marcos Caceres <marcos@marcosc.com>
- Date: Wed, 21 Sep 2016 21:56:32 -0400
- To: "Cramer, Dave" <dave.cramer@hbgusa.com>
- Cc: W3C Digital Publishing IG <public-digipub-ig@w3.org>
On September 21, 2016 at 7:36:08 PM, Cramer, Dave
(dave.cramer@hbgusa.com) wrote:
> Hi Marcos,
>
> Apologies for top-posting, but it seemed to be the format that suited my
> content :)
Blasphemy! :D
> First of all, I wanted to thank you for your contributions to this
> discussion. This is exactly what the publishing community (or at least
> me!) has hoped for over the last three years‹full engagement from the web
> community. This is awesome!
I'm just one little voice, so thank you to this group for hearing me out :)
> For quite a few years, some of us have been kicking around a set of ideas
> which I've called ³EPUB Zero². Having worked with ebooks for fifteen
> years, the complexity and insane duplication of content in EPUB have
> driven me mad. So I¹ve been wondering what the simplest possible ebook
> format might look like. The goal was to use only HTML, instead of all the
> custom XML vocabularies in EPUB.
Can see why that would be frustrating.
But remember also, HTML is just one tool in the web platform's tool box...
> A publication is, at its core, a bounded sequence of content documents.
> How could we express such an idea in HTML? It¹s almost like we need an
> ordered list of links to documents. Hmmm. If only there were an HTML
> structure that was an ordered list of linksŠ wait, there is!
>
> EPUB has always required a navigation document, as it was deemed to be
> critical for accessibility, and EPUB (to the benefit of all of us) has
> always been very focused on accessibility.
I guess you mean the ncx file here?
> And so a table of contents, in
> the form of a HTML document with a nav element, could serve to define the
> sequence of content documents. And it would have major advantages over a
> TOC generated from content (a subject for another email).
Although the focus on accessibility is great, an approach of taking
HTML elements and using them to generate a ToC in an outer process is
less than ideal.
One can express the accessible aspects of a ToC without HTML (we are
talking about just ordering and a text label here) - and it's, in
fact, desirable to do that (because native UIs are very accessible).
This is likely why . ncx files exist - and include only limited
accessibility features (explicit playOrder, and label... and that's
it!).
> Such a nav doc could contain the link to the web app manifest.
No need. The HTML already has `<link rel=manifest>` in the <head> :)
> It could be
> used as a TOC in a browser reading mode optimized for publications (as
> defined in the manifest).
Right, and so it would serve as just a ToC when viewed in the browser,
but removed via CSS when display mode is "publication". Like this:
```CSS
@media (display-mode: "publication"){
#toc {
`display: none`
}
}
```
That would be very nice!
> It could be the container for metadata that
> applies to the publication as a whole.
Whoa, don't go nuts :) Let the ToC just be a ToC.
Other metadata can go in the appropriate place... like in the header
or footer or wherever semantically in the document makes most sense.
> It would allow easy access to any
> part of the publication, even in the absence of any more sophisticated
> code in the browser, manifest, or service worker. It¹s the ultimate
> fallback.
That falls into the realm of "magic" tho, which we want to move away
from with the extensible web manifesto: magic in the sense that you
would give a HTMLNavElement (which is quite a complex object), and it
magically spits out a ToC... even if the markup is all busted up...
like it contains things set to display: none or weird custom elements.
Ideally, we would want some means to tell the browser UI what the ToC
is without throwing a bunch of HTML at it - this would require a
serious evaluation of either reusing . ncx....
```
<link rel="toc" href="toc.ncx">
```
... Or some kind of API (which could map an ncx file into a JS
structure), which could then be fed to the browser:
```JS
const xhr = new XMLHttpRequest();
xhr.open("GET", "toc.ncx");
const xml = await new Promise((resolve, reject) => {
xhr.onload = () => resolve(xhr.responseXML);
xhr.onerror = reject;
)
const ToC = Array.from(xml.documentElement.querySelectorAll("navMap"))
.map(toTocStructure)
await navigator.setTableOfContents(ToC);
```
Received on Thursday, 22 September 2016 01:57:11 UTC