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

> My point was that "publication mode" in the wiki page conflates the concept of 

> a specific UI+UX mode (à la reader mode) with the concept of an abstract set 

> of affordances that we envision for Web Pubs. Some of these affordances can

> be provided without having to "switch" to a different UI mode.

 

I'm just catching back up with these discussions, but would it make sense for there to be a scripting API for the affordances that exposes the supported "publication" features and/or exposes other aspects of the reading mode? This perhaps also overlaps with the requests for more information about the rendering during the last EPUB revision (in other words, I'm not sure exactly what it will expose or how, but it would be a way for the author-provided reading layer to shut itself off or selectively determine what features to polyfill).

 

If we don't have information like that available, then it seems like we end up in a strange place where we're asking the browser to weed out the author-provided interface (it could be done, but is there precedent for this?) or we risk overlapping feature deployment.

 

Matt

 

 

From: Romain [mailto:rdeltour@gmail.com] 
Sent: February 7, 2018 9:33 AM
To: Hadrien Gardeur <hadrien.gardeur@feedbooks.com>
Cc: 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)

 

 

On 7 Feb 2018, at 15:20, Hadrien Gardeur <hadrien.gardeur@feedbooks.com <mailto:hadrien.gardeur@feedbooks.com> > wrote:

 

2. I’m concerned that the "publication mode" terminology conflates the concepts of publication-specific affordances and publication-specific UI.

  - sometimes an affordance is directly related to UI (e.g. pagination) , sometimes not (e.g. offlinability).

 

I disagree, I think that "publication mode" MUST be 100% handled by the user agent, and never publication specific. A publication may provide a Web App as a fallback though.

 

If each publication starts implementing various features of the publication mode on their own as polyfills, we're going to have a very very hard time dealing with that in Web and native apps.

 

I used "publication-specific" to mean "Web Pub"-specific (as opposed to other Web content), not in the sense of per-publication :-)

 

 

 

  - "mode" here conflicts with WAM’s "display mode" concept, which is mostly only about UI chrome. 

 

... but this is very consistent with existing reader modes in browsers.

 

Good point.





 

  - the idea of "switching" to a "separate publication mode" makes sense for a UI, but some affordances can be provided transparently in a vanilla browser context (offlinability, next/previous links added with a speculative polyfill, etc). This concept of "separate publication mode" also kinda conflicts with progressive enhancement.

 

I really dislike polyfills in resources from the default reading order, and strongly believe that all publications should be readable entirely without any polyfill or UA specific support.

 

I agree that they should be readable.

But polyfills can be a viable way to provide some affordances IMO.





 

Reader mode in browsers is also a switch btw.

 

My point was that "publication mode" in the wiki page conflates the concept of a specific UI+UX mode (à la reader mode) with the concept of an abstract set of affordances that we envision for Web Pubs. Some of these affordances can be provided without having to "switch" to a different UI mode.

 

Romain.