Associating a manifest with publication resources

[dauwhe]

This has come up in several different threads, so it seem worthwhile to give it its own issue.

If we have a collection of information about a web publication as a whole ("manifest") that exists separately from most of the publication's resources, we need to find a way to associate the manifest with the other publicatin resources. This is necessary because we envision the manifest affecting the rendering and behavior of said web resources.

As usual, the web has already faced this problem. For example, we often use external stylesheets to control the rendering of content documents, and it's quite convenient to not have to duplicate large quantities of CSS in each HTML resource. So we use link rel="stylesheet" to associate a CSS file with an HTML file.

Web App Manifests uses exactly this mechanism to associate a manifest with a resource. But Web App Manifests also has the idea of applying a manifest to a web app:

A manifest is applied to a top-level browsing context, meaning that the members of the manifest are affecting the presentation or behavior of a browsing context.

What's interesting is that, once the manifest is associated with a particular content document, and applied to a top-level browsing context, that manifest can then affect other content documents within the scope of the manifest.

I think we have some tough choices here. Is this seemingly reasonable desideratum even possible?

1. If I navigate to a component of a WP, I should be able to discover that it's a WP and find the manifest.

[GarthConboy]

And re #1 above, is that true/false for all resources (or more likely those in the reading order), or only true for the first item in the reading order?

[lrosenthol]

On Wed, Jul 19, 2017 at 11:24 AM, Dave Cramer ***@***.***> wrote: If we have a collection of information about a web publication as a whole ("manifest") that exists separately from most of the publication's resources, we need to find a way to associate the manifest with the other publicatin resources.

Yes, I agree with this.

This is necessary because we envision the manifest affecting the rendering and behavior of said web resources.

I certainly hope that we do *NOT* have the manifest have *any* change in rendering or behavior of the resources! That would, IMO, be one of the most "anti-web" things we could do as we'd be changing the rules for processing the web resources. What's interesting is that, once the manifest is associated with a

particular content document, and applied to a top-level browsing context, that manifest can then affect other content documents within the scope <https://www.w3.org/TR/appmanifest/#navigation-scope> of the manifest.

Yes, but (a) only in the very limited set of things in the manifest that (b) the UA supports and that (c) the individual content documents don't override.

[dauwhe]

I certainly hope that we do NOT have the manifest have any change in
rendering or behavior of the resources! That would, IMO, be one of the
most "anti-web" things we could do as we'd be changing the rules for
processing the web resources.

I think the goal is that a WP-aware user agent could provide a richer experience, including UI that better allows personalization, easier access to navigation, a UI to enable easier movement from document to document, perhaps less browser chrome, etc. I already quoted language from Web app manifest that suggests the manifest may have some influence on how a web app behaves.

I hope the idea is that WP will be a way of progressively enhancing web content to serve the unique requirements of publications. I don't see that as "anti-web" :)

[lrosenthol]

On Wed, Jul 19, 2017 at 1:03 PM, Dave Cramer ***@***.***> wrote: I think the goal is that a WP-aware user agent could provide a richer experience, including UI that better allows personalization, easier access to navigation, a UI to enable easier movement from document to document, perhaps less browser chrome, etc. Maybe... I already quoted language from Web app manifest that suggests the manifest may have some influence on how a web app behaves. For a very limited set of behavior, yes. I hope the idea is that WP will be a way of progressively enhancing web content to serve the unique requirements of publications. I don't see that as "anti-web" :)

Depends on how far we go...

[HadrienGardeur]

Here's my take on this:

1. We need to offer discovery for a manifest using a link relation + media-type. This discovery could be handled either in HTML or HTTP headers.
2. Such a link could be present in any number of resources from a publication.
3. We'll have to be careful with how these links are handled and not get in the way of a Web App Manifest for instance.
4. The presence of such discovery links should be highly recommended but not required.
5. I don't think we need a scope since we're in a very different situation than a Web App. Since we're considering a declarative approach, we'll know more precisely which resources are part of a Web Publication or not.

[murata2makoto]

If I navigate to a component of a WP, I should be able to discover that it's a WP and find the manifest.

Agreed. I think that this should be recorded as one of our agreed desiderata. At this stage, I do not want to go into details more than that.

[murata2makoto]

I certainly hope that we do NOT have the manifest have any change in
rendering or behavior of the resources! That would, IMO, be one of the
most "anti-web" things we could do as we'd be changing the rules for
processing the web resources.

When I finish reading a primary resource (or a content document) in a WP, I would like to go to the next primary resource without going back to the manifest. Yes, this will be changing the rules for
processing the web resources, but I think that it is a must for WPs.

[murata2makoto]

#18 is one possibility.

[iherman]

Propose closing: The draft has a section on the issue (section 5.2)

[iherman]

Closing per https://www.w3.org/publishing/groups/publ-wg/Meetings/Minutes/2018/2018-03-12-minutes.html#resolution4