RE: Pursuing the wrong goal? (was Re: A followup/writeup on our Monday discussions (was Re: Continuing discussion on Polyfills))

> If we can't figure this out, I guess that we'll have to split things up, but there's a real risk in terms of consistency between implementations.

 

This gets to the root of what I'm puzzling. I wonder if we're overloading the manifest and instead of being a stand-in for an OPF it should simply be a way of adding a publication to a library/list. That's the one consistent experience the manifest facilitates. The reading mode/affordances perhaps don't require a manifest to be realized, so should be treated as a separate beast.

 

My next argument would then be that the table of contents and reading order are potentially misplaced in the manifest. If those are features of a reading mode, perhaps those belong in the content for authors who want to use the mode without making a publication available for addition to a library? (e.g., as prev/next/contents links)

 

Anyway, no need to belabour the point. It's just a thought experiment.

 

Matt

 

From: Hadrien Gardeur [mailto:hadrien.gardeur@feedbooks.com] 
Sent: February 9, 2018 9:08 PM
To: Matt Garrish <matt.garrish@gmail.com>
Cc: Ric Wright <rkwright@geofx.com>; Ruffilo, Nick <Nick.Ruffilo@ingramcontent.com>; Dave Cramer <dauwhe@gmail.com>; Leonard Rosenthol <lrosenth@adobe.com>; Daniel Glazman <daniel.glazman@disruptive-innovations.com>; W3C Publishing Working Group <public-publ-wg@w3.org>
Subject: Re: Pursuing the wrong goal? (was Re: A followup/writeup on our Monday discussions (was Re: Continuing discussion on Polyfills))

 

 This is where I lose consistency of logic between web pubs and WAM. The display property is only used when relaunching the app, unless I'm misunderstanding the section. So why for a web pub would it take effect in an active browsing session if nothing else happens?

 

Right, to trigger the behaviour associated to display: "publication" you'd have to "install" the publication first.

 

There's no concept that I'm aware of that would trigger a display mode without a prior installation (and then you need to launch the Web App again, from the homescreen icon for example). That's why the recent additions to the WP draft include an affordance to trigger a publication display mode.

 

There's another problem as well associated to the display-mode media query: I don't see how dedicated apps (native or web) could use it at all.

Web apps for readers mostly rely on iframes, while native apps are usually built on top of one or more webviews. There's no way to "set" a value for a display-mode (which is quite understandable), which means that in the example that I provided in my previous email, such apps would be stuck with the same behaviour as a non-WP aware UA.

 

 

And do we need to define the publication mode in the same specification that we're defining the web pub manifest, or only establish the value and give it a general description like the WAM modes?

 

I didn't mean to suggest we not consider affordances at all, only that we break them free so that they can be defined in the manner and speed that best fits the ability to realize such a mode and what it offers.

 

I'm not convinced of my own questioning here, but what I'm wondering is whether there is a way to move forward on what we can agree on without getting caught up in the part we don't?

 

We're probably spending too much time discussing "how" things could be handled.

 

IMO, we need to figure out a full list of affordances and broadly define them. If we can't figure this out, I guess that we'll have to split things up, but there's a real risk in terms of consistency between implementations.

 

Hadrien