W3C home > Mailing lists > Public > public-digipub-ig@w3.org > September 2016

Re: Rough sketch for WP, was Re: Dereferencing, was Re: Jotting down some discussion topics

From: Marcos Caceres <marcos@marcosc.com>
Date: Wed, 21 Sep 2016 21:56:32 -0400
Message-ID: <CAAci2aAdU0GwpF7J9H+c=xd2CXDQ=b6NCUsivptzr3iWV=u92A@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 25 April 2017 10:44:45 UTC