W3C home > Mailing lists > Public > public-publ-wg@w3.org > February 2018

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

From: Baldur Bjarnason <baldur@rebus.foundation>
Date: Sat, 10 Feb 2018 18:04:21 -0500
Cc: Matt Garrish <matt.garrish@gmail.com>, 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>
Message-Id: <199C998A-DABA-4A81-99AB-A68FDE0CBEBE@rebus.foundation>
To: Hadrien Gardeur <hadrien.gardeur@feedbooks.com>
I agree very much with Hadrien very much on this part:

> 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.

(Apologies for the verbosity below. Went on for way too long. TL;DR: we should start with a list of affordances before we worry about implementation or even modes.)

We’ve outlined the data needed (the infoset covers this well). Now we need to be more specific about the exact ways that data should be represented (i.e. affordances). Only once we’ve done that can we get into how those representations are implemented.

Being specific about how the data is represented to the reader as affordances matters a lot as that informs both how the data is best encoded and how the affordance is implemented.

The implementation itself backing the behaviour can vary a lot. E.g. reading order could be turned on and feature-detected as a part of a display-mode, which would be the logical thing to do when building on the WAM.

You could also argue that the History API creates precedent for exposing reading order as a DOM API instead and that tying it to a display-mode needlessly prevents non-publication websites from using it. 

The affordance could be detected via a Reading Order API and if that API isn’t used, the UA would use what the WAM provides for reading order, much in the same way that if you don’t touch the History API the browser just uses its default behaviour. And an API-first implementation design has the benefit of being more easily testable.

Or reading order could be done as both, defined as its own feature but commonly triggered by a change in display mode (or maybe an API call if you aren’t in ‘publication mode').

And if you model the ToC as primarily navigations to and from a ToC resource, you could build that feature the same way.

So the same affordance, delivered in the same JSON structure could be implemented in multiple different ways, each with their pros and cons, each with different tradeoffs. And it’s hard to tell which implementation approach is best until we have a list of all of the affordances, get a sense of how they would behave in practice, and can look at the issues they have in common (or don’t).

The important thing to note here is that these tradeoffs and needs could be different for each affordance. We can’t assume that they are best served all bundled together in a single ‘publication mode’ implementation, no matter whether that mode is something we invent or base on WAM display-modes.

We also need to bear in mind that many of the concepts of web publications have general value:

- A ToC is basically a structured navigation menu for a group of web pages
- A reading order is a pre-defined sequence of web pages, which is an extremely common pattern in websites.
- A lot of sites could benefit from simpler offline storage.
- If we can get user-preference values into the env() function proposal for CSS Variables 2 then that would benefit the entire web and not just publications

So even though these features would probably initially be implemented as a part of a publication mode there would be a huge upside in having a design for these affordances that works outside of that mode, once the features have proven themselves.

Besides, any feature whose implementation can be designed as ‘always on’ and mode independent is probably going to be easier to build and polyfill, all else being equal. 

You could have APIs in one of three states:
- Absent (unimplemented)
- Present but empty (i.e. the UA hasn’t loaded any data from the manifest, but you could load data programmatically to get natively-implemented affordances).
- Present and automatically filled with data from the manifest (i.e. in ‘publication mode’)

Anyway, most of these thoughts are pretty darn half-baked by necessity as AFAICT we don’t have a concrete list of affordances yet.  But i think it’s clear that we have an abundance of approaches available to us. 

I’m sure that once we have a manageable list of behavioural affordances we can aim for, and with a bit of work, we can figure something out that everybody—browsers, publishers, reading systems—can be excited about.

- best
- Baldur Bjarnason
  baldur@rebus.foundation



> On 9 Feb 2018, at 21:08, Hadrien Gardeur <hadrien.gardeur@feedbooks.com> wrote:
> 
>  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
Received on Saturday, 10 February 2018 23:04:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:52:21 UTC