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

+1000. Can't agree more.

Best,
Romain.

Le 8 févr. 2018 7:43 PM, "Baldur Bjarnason" <baldur@rebus.foundation> a
écrit :

> This entire thread worries me and I know that it has caused others who are
> familiar with both web development and ebooks a lot of anxiety.
>
> Part of my worry stems from confusion: I’m not entirely sure I understand
> what’s going on in this thread or what people are proposing.
>
> The other concern is, that if I understand the discussion correctly
> (which, like I said, is not certain), the proposals so far look like a
> fundamental departure from how modern web development works:
>
> - There is no precedence for anything remotely like a “WP Script” resource
> that is removed, disabled or rewritten by aware UAs. I can’t think of
> anything modern that does the same. The only thing that’s even remotely
> similar is the media attribute on the link element but that is a general
> purpose mechanism not tied to a specific feature, builds on built-in
> features of CSS, and doesn’t apply to scripts. The “WP Script” proposal is
> conceptually pretty alien to modern web development practice. If I’ve
> understood it correctly.
>
> - Using different resource locations for UAs with different capabilities
> as some proposed—that is one location for the publication proper and
> another for UAs that don’t support web publications—is _exactly_ the
> approach the web development community has been trying to migrate away from
> over the past years. Similar tactics in the past (e.g. special domains for
> mobile) have been the cause of a huge number of maintenance and
> functionality issues as well as high costs. Proposing to revert to those
> tactics will be extremely unpopular among web developers.
>
> - Like others have previously mentioned, bundling all publication-related
> features in an all-or-nothing loading process both breaks away from how
> most specs are authored these days and seems to actively prevent the
> potential reuse of these features outside of a bespoke ‘publication-mode’.
> We should be discussing these affordances as individual features, not
> jumping ahead to an invented from scratch, all-or-nothing mode-switching
> mechanism that seems to presuppose browser vendor non-participation.
>
> - Finally, all of the proposed processes in this thread disregard the
> built-in mechanisms of the Web Application Manifest for fallback and
> adaptation.
>
> Specifically, the Web Application Manifest has a built-in mechanism for
> changing application UI modes: display-mode.
>
> This mechanism is specified to default to ‘browser’ when it encounters an
> unknown or invalid display mode, providing a reasonable fallback for new
> values.
>
> It is exposed as a value for CSS media queries which, with
> window.matchMedia, serve as the primary mechanism for the web site to
> detect and adapt to a new display mode.
>
> And they aren’t specifically tied to installed web apps. As the WAM spec
> says: "the user agent MAY provide the user with a means of switching to
> another display mode.”[^1]
>
> This is how the WAM works and is being implemented by every major browser
> vendor on every OS.
>
> I’m not saying that all web publication features should be tied to a
> ‘publication’ display-mode as display modes are clearly only meant for
> basic browser-UI affordances. Like I stated above, I think we first need to
> outline features individually before we decide on wether they are APIs, a
> part of a display-mode, or basic extensions of HTML or whatever else we can
> think of.
>
> But I also find it very hard to see the proposals in this thread as
> anything less than a refusal to work with or build on the Web Application
> Manifest both as a format and as a mechanism.
>
> I am pretty sure that this is not the intent for most members of this WG
> so I have to assume that there has been some sort of horrible failure of
> communication or major misunderstanding on my part that needs to be cleared
> up as soon as possible.
>
> In any case, I am still not sure I’ve actually understood the discussion
> in this thread. Maybe I’m the only one. But I find it likely that if I’m
> having problems, so are others. And if I’ve completely misunderstood the
> proposals, I doubt I’m alone in my misunderstanding.
>
> [^1]: https://www.w3.org/TR/appmanifest/#dfn-display-mode
>
> - best
> - Baldur Bjarnason
>   baldur@rebus.foundation
>
>
>
> > On 8 Feb 2018, at 03:29, 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
> >>
> >> E: hadrien.gardeur@feedbooks.com
> >>
> >> 54, rue de Paradis
> >>
> >> 75010 Paris, France
> >>
> >>
> >
> >
> > ----
> > Ivan Herman, W3C
> > Publishing@W3C Technical Lead
> > Home: http://www.w3.org/People/Ivan/
> > mobile: +31-641044153
> > ORCID ID: http://orcid.org/0000-0003-0782-2704
> >
>
>