Re: JS - inside or out?

On Wed, Nov 16, 2016 at 8:32 PM, Leonard Rosenthol <lrosenth@adobe.com>
wrote:

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

Indeed -- not was I was saying.  Just want to avoid any *requirements* that
the rendering JS be included with the publication -- should be able to have
a very simple publication that's rendered completely independently of
content.


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

Hmmm... might argue some of that (content versus Reading System)... but,
yes, for discussion!  :-)

Best,
   Garth


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