Re: JS - inside or out?

> On 17 Nov 2016, at 06:51, Leonard Rosenthol <lrosenth@adobe.com> wrote:
> 
> 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.

I am fine with this — in general.

However, if we go down the route of profiling for various communities, we may hit different requirements and some communities MAY want to choose one way or another. It is therefore very important for us to have a clear image of the two approaches; the demos of Dave and Hadrien were excellent means to draw attention on these.

Ivan



> 
> 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 <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 <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 <https://github.com/banux/webpub-streamer>
> 
> Hadrien
> 


----
Ivan Herman, W3C
Digital Publishing Technical Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704