- From: Baldur Bjarnason <baldur@rebus.foundation>
- Date: Fri, 9 Feb 2018 10:55:31 -0500
- To: Ivan Herman <ivan@w3.org>
- Cc: W3C Publishing Working Group <public-publ-wg@w3.org>
Ivan, I’m not sure I agree with the premise. Web development has a pre-existing set of tactics that help a website respond to its context. Modern browsers and web development generally work along those lines: the browser exposes features that can be queried in some way; the web site uses those to adapt to its context. And it generally isn’t done on an all or nothing basis. As in, flipping into mobile mode when touch pointers are present is a bad practice in a world with tablets and touch-capable laptops. So you respond to the presence of touch gestures and small screen sizes separately. These are the web development tactics that browser vendor explicitly favour and promote and they provide a bunch of useful APIs and capabilities to support it: @supports, @media, matchMedia, WAM display-mode and JS feature detection. IMO, we have to work with these basic capabilities of the modern instead of inventing a new loading process from whole cloth and that means we can’t too aggressively bundle all of the web publication features behind a single process. * UI affordances should probably be a display mode and detected via the display-mode query. * Offline storage probably needs to be exposed via a DOM API somehow. This could be as simple as querying the Cache API to see if your resources have been saved by a publication-aware client or as complex as a fully featured extension to the Cache API for loading resources from a list. I don’t see any other way for the WG other than to go through the affordances, one by one, and figure them out individually. We can deliver them as a single spec but they have to be figured out individually, preferably in closer collaboration with browser vendors than we have done so far. Many of these discussion might have to take place in venues where they are more active: the WAM spec issues, WhatWG issues, or the WICG. In any case, whichever path the WG takes, I won’t be able to participate that much for at least a few weeks. Rebus’s projects are keeping us all quite busy. - best - Baldur Bjarnason baldur@rebus.foundation > On 8 Feb 2018, at 14:31, Ivan Herman <ivan@w3.org> wrote: > > Baldur, > > would it be possible for you to write down what, in your view, a realistic architecture for bootstrapping a WP environment should look like (eg, via a Wep App with WAM)? Mind you: one of the difficulties is that whatever one publishes as a WP should be displayable by a WP aware reading system without running any extra script (ie the one that is necessary for a non-WP-aware browser...) > > Thanks? > > Ivan > > --- > Ivan Herman > Tel:+31 641044153 > http://www.ivan-herman.net > > (Written on mobile, sorry for brevity and misspellings...) > > > >> On 8 Feb 2018, at 19:43, Baldur Bjarnason <baldur@rebus.foundation> wrote: >> >> 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 >>> >> >
Received on Friday, 9 February 2018 15:55:59 UTC