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 04:32:37 +0000
To: 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: <98C39B61-F0F1-43FD-B0E3-4F3E8AFE9634@adobe.com>
Well, lack of support for ANY JS in a WP would make them quite limited in capabilities  (see various UCR use cases for examples) – so I hope that wasn’t really what you meant…

I think that whether we will even have a definition of an RS – or simply have standard OWP UA’s – is going to be quite the conversation.   However, regardless of that, I think it is very important that we enable publications to provide their own layout and/or pagination engine (such as Florian’s Vivliostyle) instead of relying on whatever might exist in the RS/UA.

Leonard

From: Garth Conboy <garth@google.com>
Date: Wednesday, November 16, 2016 at 5:40 PM
To: 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?

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 04:33:15 UTC

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