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> 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
>