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

Re: JS - inside or out?

From: Hadrien Gardeur <hadrien.gardeur@feedbooks.com>
Date: Wed, 16 Nov 2016 11:48:36 +0100
Message-ID: <CA+KS-13RpziwoKr3OGc883_a5SqyY8sz+h6t+qkhLJpwZn2jHg@mail.gmail.com>
To: Ivan Herman <ivan@w3.org>
Cc: Leonard Rosenthol <lrosenth@adobe.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
Hello,

I don't think that this is a choice that we should be mandating either,
these are simply two different use cases.

For publications that are truly native to the Web, they can either decide
to provide a fallback for progressive enhancements that might be missing in
browsers currently, or completely ignore them.
These types of publications are IMO much more likely to embed JS, but it
remains entirely their choice.
We just need to figure out a way to:

   - identify that a JS provides such progressive enhancements in order to
   turn it off eventually
   - make sure that each progressive enhancement can be tested
   individually, this way we can have a much more fine grained approach for
   such a "Web Publication Polyfill"

I've listed a few of the progressive enhancements that could be supported
at:
https://github.com/HadrienGardeur/webpub-manifest/wiki/Web-Publication-JS-Features

For publications that are not native to the Web (for example when an EPUB
is turned into a Web Publication), I think we're much more likely to see JS
used for a separate Web App that behaves like a reading system/app.
This is what Dave has built with ACME JS, and I've also built a similar
prototype at: https://github.com/HadrienGardeur/webpub-viewer
Someone from my team at Feedbooks (Bastien Quelen) even built a simple
prototype in Go that takes an EPUB and:

   - generates a Web Publication Manifest on the fly using the info
   extracted from the OPF
   - streams individual resources from the publication using HTTP

This project is available at: https://github.com/banux/webpub-streamer

Hadrien
Received on Wednesday, 16 November 2016 10:49:30 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:36:35 UTC