Re: A followup/writeup on our Monday discussions (was Re: Continuing discussion on Polyfills)

I think that processing model has issues when the UA in question is not the
browser. If I write an extension, will I be able to process the document
after the DOM loads, but before scripts are loaded and run? I honestly
don't know, I have never written an extension for any browser, and it seems
likely that the answer to that question is browser dependent. I am just not
sure how easy it will be in practice for an extension (or something else)
to remove that script. I am also not sure why we need it. There is nothing
stopping me, as a web site owner, from having two links on my site - one is
a raw link to the content of the publication, the other is a link to a web
app that will load that publication. If I follow the first link and have a
WP aware UA, it launches and I have access to all the features I want. If I
am not WP aware, I just see a web page. If I follow the second link, I get
that web app regardless of whether my UA is WP aware or not. I had been
under the impression that the fallback for non-WP aware UA was just a basic
web page. You can still read the publication, but maybe there is no chapter
nav, or full search, or whatever, but you can still read the thing. Adding
this "it's data and an app, but you can strip the app if you want to just
turn it into data" seems complex and unnecessary.

On Thu, Feb 8, 2018 at 12:29 AM, Ivan Herman <ivan@w3.org> wrote:

> Seeing the discussion thread… Let me try to put my "mental model" on the
> subject of the WP script into some more algorithmic terms. Obviously, the
> details are fuzzy, and may be unrealizable, but then we have to find out
> what IS realizable.
>
> The sketch below does not take into account a possible usage of the
> Publication manifest on top of a WAM. It may actually simplify the process
> to have the WAM included, based on the fact that some of the elements may
> already be implemented by WAM aware browsers. (I would welcome if somebody
> did a version with WAM included…).
>
> With that:
>
> * The user agent accesses the entry page of a publication.
> * If the User Agent is WP aware:
> * If the entry page includes a reference to a Web Publication manifest
> * If the entry page includes a reference to a specific script (currently
> referred to as "WP script", possibly identified via something like
> type="application/javascript;profile=http://.../publication") this script
> is ignored (reference removed from the DOM)
> * It retrieves the manifest (see the lifecycle) and enters the publication
> mode
> * Otherwise, the entry page is processed as a traditional Web page
> * Otherwise, the user agent handles the entry page as a traditional web
> site:
> * If the entry page includes a reference to a WP script, that is included
> and started by the UA just like any other javascript. The WP script:
> * If the entry page includes a reference to a Web Publication Manifest:
> * Consumes the manifest as described in the lifecycle
> * Enters the UA into a publication mode
> * The script stops, letting the user agent proceed with the entry page as
> a traditional web site
> * Nothing happens, the page is just processed as a traditional web site
>
> The goal is to define what happens if a WP is given to a UA that does
> _not_ have any WP awareness whatsoever and whether we can have en
> environment whereby the publication has a fall-back minimal publication
> mode in that case. Note that, in this respect, a browser with a WP specific
> extension should be considered as "WP aware".
>
> We _may_ decide that all this is too complicated or unrealistic to
> implement, and we should rely on WP aware browsers only. This is a decision
> we have to take because that may influence the core architecture. What it
> would mean is that users would have to install an extension to turn it into
> WP aware. If that is the way we go, then we can ignore many things and even
> the definition of fall-backs. However, the question that comes to mind is
> whether the deployment of Web Publications would become realistic on the
> Web if each and every user had to install a specific extension.
>
> (Before jumping into the extension-only approach we should see whether
> something like the outline above could be achieved via a WAM controlled
> application!)
>
> Taking into the multitude of browsers out there. An extension is not
> browser engine specific, but may be browser specific! Ie, if I run the
> Brave browser as my default browser, a Chrome extension would not be
> necessarily installable for Brave, in spite of the fact that it uses
> Chromium as its core engine. Such "other" browsers are out there and, in
> some countries like China or Russia their usage may be more important than
> one of the big four...
>
> Ivan
>
>
>
>
>
> On 7 Feb 2018, at 21:52, Brady Duga <duga@google.com> wrote:
>
> +1 to Hadrien. I thought the whole point of this little web adventure was
> to have publications that just work, today, out of the box, with no client
> other than a browser. A UA could also then apply more UI and navigational
> elements around that publication if it was capable, which is what we are
> trying to spec (how do you know the order of the chapters in a book, what
> is the title of the complete package, etc). This idea of a script
> associated with the document to provide some of those behaviors seems
> really problematic, again as Hadrien pointed out, when the UA supports some
> of the features and the script supports others. I am still not sure why a
> separate web app, extension, or whatever can't accomplish this just as
> well. But I am assume I am missing another discussion where we explained
> why we need the WP script.
>
> On Wed, Feb 7, 2018 at 12:25 PM, Matt Garrish <matt.garrish@gmail.com>
> wrote:
>
>> Right, okay now I've got you, thanks for clearing that up for me.
>>
>>
>>
>> Matt
>>
>>
>>
>> *From:* Hadrien Gardeur [mailto:hadrien.gardeur@feedbooks.com]
>> *Sent:* February 7, 2018 3:22 PM
>>
>> *To:* Matt Garrish <matt.garrish@gmail.com>
>> *Cc:* Romain <rdeltour@gmail.com>; Ivan Herman <ivan@w3.org>; W3C
>> Publishing Working Group <public-publ-wg@w3.org>
>> *Subject:* Re: A followup/writeup on our Monday discussions (was Re:
>> Continuing discussion on Polyfills)
>>
>>
>>
>> The entry page could indeed have a link to a WAM or it could simply
>> provide a link that the user could follow as well.
>>
>>
>>
>> 2018-02-07 21:12 GMT+01:00 Matt Garrish <matt.garrish@gmail.com>:
>>
>> > The entry page would link to the fallback app, no need for a link in
>> the manifest or for the browser to be WP-aware.
>>
>>
>>
>> Ah, so this isn't like having a default_applications for fallback apps,
>> but the entry page is its own WAM?
>>
>>
>>
>> Matt
>>
>>
>>
>> *From:* Hadrien Gardeur [mailto:hadrien.gardeur@feedbooks.com]
>> *Sent:* February 7, 2018 2:48 PM
>> *To:* Matt Garrish <matt.garrish@gmail.com>
>> *Cc:* Romain <rdeltour@gmail.com>; Ivan Herman <ivan@w3.org>; W3C
>> Publishing Working Group <public-publ-wg@w3.org>
>> *Subject:* Re: A followup/writeup on our Monday discussions (was Re:
>> Continuing discussion on Polyfills)
>>
>>
>>
>> The entry page would link to the fallback app, no need for a link in the
>> manifest or for the browser to be WP-aware.
>>
>>
>>
>> This wouldn't get in the way of other apps for the following reasons:
>>
>>    - a WP-aware browser would trigger the "switch to publication mode"
>>    or "add to publication list" affordances on the entry page (or any other
>>    page with a link to the manifest)
>>    - web and native apps (including browser extensions) would only use
>>    the entry page to detect the link as well, and then they would immediately
>>    go to the first resource in the default reading order
>>
>>
>>
>>
>>
>> --
>>
>> Hadrien Gardeur
>>
>> Co-founder, Feedbooks
>>
>> http://www.feedbooks.com
>>
>> T: +33.6.63.28.59.69 <+33%206%2063%2028%2059%2069>
>>
>> E: hadrien.gardeur@feedbooks.com
>>
>> 54, rue de Paradis
>> <https://maps.google.com/?q=54,+rue+de+Paradis+75010+Paris,+France&entry=gmail&source=g>
>>
>> 75010 Paris, France
>> <https://maps.google.com/?q=54,+rue+de+Paradis+75010+Paris,+France&entry=gmail&source=g>
>>
>
>
>
> ----
> Ivan Herman, W3C
> Publishing@W3C Technical Lead
> Home: http://www.w3.org/People/Ivan/
> mobile: +31-641044153 <+31%206%2041044153>
> ORCID ID: http://orcid.org/0000-0003-0782-2704
>
>