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

Re: JS - inside or out?

From: Leonard Rosenthol <lrosenth@adobe.com>
Date: Thu, 17 Nov 2016 14:51:37 +0000
To: "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com>, Garth Conboy <garth@google.com>, Hadrien Gardeur <hadrien.gardeur@feedbooks.com>
CC: Ivan Herman <ivan@w3.org>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
Message-ID: <88241F7C-9DA7-45AD-9503-256D0F3C9B94@adobe.com>
I think we all agree that we don’t want to REQUIRE this.

But at the same time – I believe that we would like to ALLOW this, if a given publication has specific needs.

Leonard

From: "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com>
Date: Thursday, November 17, 2016 at 7:58 AM
To: Garth Conboy <garth@google.com>, Hadrien Gardeur <hadrien.gardeur@feedbooks.com>
Cc: Ivan Herman <ivan@w3.org>, Leonard Rosenthol <lrosenth@adobe.com>, W3C Digital Publishing IG <public-digipub-ig@w3.org>
Subject: RE: JS - inside or out?

I’m with Garth.

Tzviya Siegman
Information Standards Lead
Wiley
201-748-6884
tsiegman@wiley.com<mailto:tsiegman@wiley.com>

From: Garth Conboy [mailto:garth@google.com]
Sent: Wednesday, November 16, 2016 8:40 PM
To: Hadrien Gardeur
Cc: Ivan Herman; Leonard Rosenthol; W3C Digital Publishing IG
Subject: Re: JS - inside or out?

My 2-cents is we can't/shouldn't get to any place that requires any part of the Reading System (or really any JS) be included/embedded-in a PWP publication.

Best,
   Garth


On Wed, Nov 16, 2016 at 2:48 AM, Hadrien Gardeur <hadrien.gardeur@feedbooks.com<mailto:hadrien.gardeur@feedbooks.com>> wrote:
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 Thursday, 17 November 2016 14:52:15 UTC

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