Re: Notes about the Web App manifest document

Hi Mike,

Difficult to call this a Publication. The related stuff called by the main page is not accessible when WIFI turned off. See for instance "Groups"

This single HTML page isn’t representative of any publication we do know as publishers and will do in the future.
As it was already largely discussed here, a single HTML file cannot be a PWP in almost all use cases.

Luc

De : Mike Perlman <perlmanm@me.com<mailto:perlmanm@me.com>>
Date : vendredi 3 juin 2016 11:37
À : Bill McCoy <bmccoy@idpf.org<mailto:bmccoy@idpf.org>>
Cc : Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>, "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com<mailto:tsiegman@wiley.com>>, Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>, W3C Digital Publishing IG <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Objet : Re: Notes about the Web App manifest document
Renvoyer - De : <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>
Renvoyer - Date : vendredi 3 juin 2016 11:38

Hi Bill

I took up your challenge and made a PWP of your suggested page -  https://www.w3.org/2016/09/TPAC/.
You can view it here - http://samples.5doc.org/content/w3c-tpac-2016/ - just click the 5DOC button on the left to download it and open it in a browser. Don’t forget to turn off the WiFi! I added reference links in the modal.

The downloaded file size is 342kb and 157kb compressed. The Safari generated PDF is 215kb.
The PWP-5DOC looks much better than the PDF. Once browsers offer on the fly compression, clearly a single file PWP in this use case would be superior on all accounts to a PDF.

The on and offline sample also looks fine in Chrome, but there are some problems in FireFox.

For those interested - below I have provided a list of the steps taken to produce the sample.

Cheers
Mike


********
If a 5DOC plugin was built into the CMS there would be almost no work to make an offline version
With the current system these are the steps:

1. Copy source - convert enitities.
2. Paste the content - usually first element after body into WordPress “Edit Content” box.
3. Paste all the CSS sequentially into a CSS content type “Edit Content” box, including internal CSS.
4. Add images locally. They will be encoded on the fly into Base64.
5. As my WordPress install uses a multiple themes plugin (not needed for normal sites) - I add the new URL to settings and assign it to a bare bones theme.
6. Config post settings - some basic stuff can be added like moving the modal, adding inline CSS to body, adding internal style sheet to eliminate any incompatibilities.
7. Download "League Gothic Regular" from Font Squirrel. Go to Font Squirrel’s Generator Page and convert the font to WOFF with Base64 encoding. Download. Copy the data into the CSS making sure the font family name is as it was in the original stylesheet. BTW I think there was an error in the CSS entry for Gill Sans, which I fixed and now it’s using my machine's Gill Sans font.
8. I used moblefish.com<http://moblefish.com> to encode the SVG to base64. This is the first time I did this. In previous samples I used the raw SVG. I love SVG, but I am still confused by the different methods to embed it.

At this point, the offline version is ready. There are still some conflicts between the online version and the other CSS used by WordPress. In a normal use case these problems wouldn’t exist as the CMS environment would be configured.

For online, I added two overrides and left one problem:
1. I adjusted the width of the online container to conform with the original.
2. There was an ID conflict which I hacked past - #content is used as a high level ID for WordPress and section ID in the sample.
3. I couldn’t figure out why the nav is taller online. It looks fine offline.

Then I added some details about the in the modal - opened by the hamburger icon.

********



On 02 Jun 2016, at 11:14, Bill McCoy <bmccoy@idpf.org<mailto:bmccoy@idpf.org>> wrote:

+1 Leonard (wow, a pattern emerging??).

To be clear I too don't see the primary use case being web site = PWP,  in most cases, but I do see the isomorphism with a "microsite"... which is not a well-defined term in the Web architecture domain AFAIK (actually neither really is "web site" but at least there you have the expectation of domain = site).

By way of example I could argue that while W3.org<http://w3.org> isn't a "Web Publication" that  https://www.w3.org/2016/09/TPAC/ could constitute a Web Publication. In it the first link (back to W3C home) is not itself pointing to "part of" the publication, nor is the "More W3C Events" link or other links to external content. But overall it has an ordered list of resources that you can navigate to and you could imagine wanting to consume it either linearly (reading it all one thing at a time) or via navigation. From an a11y perspective having discoverable navigation to "the content" of this "microsite" makes sense to me. This is not a perfect example because the linearity is relatively low (e.g. there's no strong reason that "participation rules" should be considered to come *before* "registration). But it's much more like a publication than it is like an app. And back to our points of agreement, it's certainly not just a single web page.

--Bill


On Thu, Jun 2, 2016 at 2:00 PM, Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> wrote:
Jumping back in…

I believe that a PWP is about publications - not just documents, but many different digital experiences.  That means that from a technical perspective, I would expect that a PWP might well contain a game or video (or both).  However, philosophically, I don’t believe that either (games or videos) should be the primary piece of a publication.  A good example is a textbook which would have these things and more to engage and interact with the reader.   But having “Gmail” or “Tetris” as a PWP – not really what I am hoping we are focused on.

In the same vein, there is also a difference between a clearly author-intended publication and a web site.  I wouldn't expect (or for that matter necessary want to see) something like Wikipedia to be “bundled” as a PWP.  Sure, you might extract some of that content for the express (author-intended) purpose of publication – but not all of it (which isn’t intended to be published in that fashion).

Bill, I agree with you (again, not trying to establish a pattern) that a PWP isn’t necessarily a single HTML resource.  It could be – but doesn’t have to be.  The definition in the spec, which you quoted, is well put together and reflects the conversations to date about possible use cases for PWP.  And because of that, we absolutely do need (as you mention) some form of navigation model – whatever form it may take.

Leonard

From: Bill McCoy <bmccoy@idpf.org<mailto:bmccoy@idpf.org>>
Date: Thursday, June 2, 2016 at 3:47 PM
To: Mike Perlman <perlmanm@me.com<mailto:perlmanm@me.com>>
Cc: "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com<mailto:tsiegman@wiley.com>>, Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>>, Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>>, W3C Digital Publishing IG <public-digipub-ig@w3.org<mailto:public-digipub-ig@w3.org>>

Subject: Re: Notes about the Web App manifest document


Mike I wasn't necessarily suggesting any course correction I was just making a perhaps ill-advised parenthetical remark in the midst of misunderstanding the nature of the debate between Ivan and Leonard. But I will express my $.02 that:

- if the PWP vision intends to solve the online/offline+packaged/distributed problem for Web content in general  - including things like my examples of javascript games and videos that seem to fit the current definition of "Web Publication" - then yes I think we should say so, that's not a course correction that's just calling a spade a spade given that the charter of this group references "document publishing". If we're solving a broader problem then great but let's say so ... that's just being honest not a course correction. Or, if we're not then let's be honest about that and that might be a course correction if some folks have been imagining we were. I like the aspiration to solve the broader problem because it clarifies that the scope of PWP work is much broader than EPUB. But it also makes it clear that this is really a Web architecture thing not an electronic document thing.

- if the PWP vision can be interpreted as being limited to a single HTML web page then I think we need some wordsmithing. While I take issue with the broad definition of "Web Publication" (as including much more than "documents" but kind of obscuring that it does so)  it is clearly stated that a Web Publication "is an aggregated set of interrelated Web Resources". Of course such resources may be HTML documents. But nothing in that definition says that the whole is necessarily encapsulated in a single HTML document and the "aggregated set" implies it could be otherwise. I happen to personally think that a Web-native realization of the vision could benefit if an HTML document (which includes SVG content as well) was the canonical entry point vs. expecting a processor to handle something else like XML or JSON. But being the entry point to a publication doesn't mean that it is *the* publication.

- re: <nav> I consider it a feature not a bug that it is missing from the current PWP vision document - actually the word navigation isn't in there at all. But that just reinforces my point that the work so far on solving for online/offline+packaged/distributed seamlessness hasn't really been about what I would call "document publishing". I think it's goodness that PWP work to date has focused on solving a BHAG and one which is not already solved in e.g. EPUB but that doesn't mean that this work to date covers everything that's going to be needed to fully encompass native Web portable documents. So I'm not so much suggesting a course correction as noting en passant that some more work needs to be done. I do think it's relevant to the manifest question though because to me the thing that's clearly distinct about a document manifest from an app manifest is that the former has order and (ideally) navigation, the latter does not. But if this group wants to focus on the superclass first - the Web Manifest - great.

--Bill


On Thu, Jun 2, 2016 at 11:34 AM, Mike Perlman <perlmanm@me.com<mailto:perlmanm@me.com>> wrote:
So this would be a “course correction”, as <nav> is not mentioned in the latest version of Editor’s Draft (16 May 2016 - https://w3c.github.io/dpub-pwp/) nor does its “Vision” mention the requirement of more than one HTML page. Of course a <nav> with internal links on a single html page could be useful.

Also, it is possible to have multiple pages without multiple HTML files - as is the case of an EPUB or in some of the 5DOC samples (using fullpage.js and reveal.js). So this requirement would be unprecedented as well as another course correction.


Cheers
Mike


On 02 Jun 2016, at 08:03, Bill McCoy <bmccoy@idpf.org<mailto:bmccoy@idpf.org>> wrote:

And, taking this up a level of abstraction from a11y concerns, the linear order and outline of <body> works perfectly well in the case where the entire publication is comprised of a single HTML file and it could be argued that in that base case no additional <nav> is necessary. But the more general case of Web content is composite publications in which more than one resource comprises the content. Resources can be strung together with rel=next but that does not enable random-access navigation to the whole from any point (unless the whole be pre-fetched and pre-digested). In effect a Publication (in my proposed abstract definition as well as concretely in EPUB) is analogous to a Web site / microsite more than it is to a Web page. The term "weblet" was once coined to cover this [1]  but it didn't stick. So HTML5 is the key building block but a single HTML5 document is not necessarily the whole thing.

Conversely not all web pages with a head and body are publications. Where the body is just an empty div that javascript populates on the fly that is not something that has a canonical order or reliable navigation into it. When a web page is the equivalent of an X window session it is not a publication even though it is still HTML5.

--Bill

[1] http://alglobus.net/NASAwork/papers/RNR-94-017/RNR-94-017.html


On Thu, Jun 2, 2016 at 10:44 AM, Siegman, Tzviya - Hoboken <tsiegman@wiley.com<mailto:tsiegman@wiley.com>> wrote:
https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms.html

Tzviya Siegman
Information Standards Lead
Wiley
201-748-6884<tel:201-748-6884>
tsiegman@wiley.com<mailto:tsiegman@wiley.com>

From: Mike Perlman [mailto:perlmanm@me.com<mailto:perlmanm@me.com>]
Sent: Thursday, June 02, 2016 1:43 PM
To: Bill McCoy
Cc: Ivan Herman; Leonard Rosenthol; Siegman, Tzviya - Hoboken; W3C Digital Publishing IG
Subject: Re: Notes about the Web App manifest document

Hi all

I think I have seen the suggestion about <nav> previously.

What is the importance of <nav> to PWP?

Why not just html, head, body as in HTML5?

Cheers
Mike


On 02 Jun 2016, at 07:34, Bill McCoy <bmccoy@idpf.org<mailto:bmccoy@idpf.org>> wrote:

Ivan, my bad I didn't notice that Leonard was quoting you in his email and thus when you were disagreeing with his detailed suggestion  you obviously didn't have to clarify that you agreed with the higher-level point... since it was yours. That's what I get for dropping in midway on a long thread, sorry.

--Bill

P.S. I do still have a quibble about the broad/vague definition of "Web Publication" in the current PWP manifesto, that probably corresponds to a broad/vague definition of "Web App" by that group... I think some of the issue is that both efforts are really trying to solve broader problems but yet may feel that they have  "rope" only to solve problems for a narrower set of use cases leading among other things to unclear terminology.


On Thu, Jun 2, 2016 at 10:27 AM, Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>> wrote:
Bill,

just a quick note from my below. TL;DR: We actually don't disagree...

---
Ivan Herman
Tel:+31 641044153<tel:%2B31%20641044153>
http://www.ivan-herman.net<http://www.ivan-herman.net/>

(Written on mobile, sorry for brevity and misspellings...)



On 2 Jun 2016, at 18:00, Bill McCoy <bmccoy@idpf.org<mailto:bmccoy@idpf.org>> wrote:
Well, not to set precedent by agreeing with Leonard ;-) but Ivan I think you missed part of his point (with which I do agree): we should have a more general "Web Manifest" which could then be specialized as necessary for "Web Apps" and "Web Publications", not trying to build on something already specialized for "Apps".

Isn't it what I said? In any case that was my intention to say: the problem I see with the current manifest document is that it is a Web App Manifest instead of a generic manifest that can be "subclassed" to a Web App or a Web Publication manifest.

Ivan

That seems worthwhile independently of debates about e.g. JSON (I do agree with you on this and since EPUB already is ZIP-based as is almost everything else under the sun I am not offended by the idea of evolving towards a universal Web packaging that is ZIP+JSON rather than ZIP+XML).

But back to Leonard's higher-level point: I still think with PWP we are a bit too liberal about what we mean by "Web Publication" [1] at least as regards the current scope of the IG. I could take this definition as inclusive of for example a casual game written in JavaScript (so all its essential functionality is there and it is usable offline). But of course the Web Apps folks would consider that an "App", as they should. And the Holy Grail that PWP seeks to solve (Web content that is seamlessly usable online and offline and whether its constituent resources are packaged or distributed) applies equally well to such apps (albeit not client-server apps) as well as other types of content that might be argued to be beyond the scope of our charter (such as videos). I think it's great if PWP solves bigger problems that help OWP overall but let's call a spade a spade - if we are solving the online/offline packaged/distributed seamlessness for web content in general then it is  just "Web" not "Web Publications" or "Web Apps".

And if we want a more crisp definition of what is really a "Publication" that sits fully within the scope of the current IG charter and participants (and I think we do) my candidate is that a publication is any Web content that has a defined order for its essential content and provides discoverable navigation into it. That is to me what makes EPUB EPUB, not the details of *how* those things are defined in EPUB 3. And doing so could be as simple as saying any Web content that designates a <nav> element that provides these things qualifies as a "Publication".

--Bill

[1] http://w3c.github.io/dpub-pwp/#pwp_definition

On Mon, May 30, 2016 at 2:54 AM, Ivan Herman <ivan@w3.org<mailto:ivan@w3.org>> wrote:

> On 29 May 2016, at 18:27, Leonard Rosenthol <lrosenth@adobe.com<mailto:lrosenth@adobe.com>> wrote:
>
>> Maybe we can agree in some sort of a 'core' set of term for a Web Manifest (and not Web *App* Manifest), which can then be adapted for different constituencies
>>
> Not just for constituencies but also potentially for grammars and/or serializations.  The plan to use JSON vs XML vs. ??? is still before us,

Well… I have the impression that this boat has sailed, but that is my personal impression. The Web Community has voted with its feet, so to say, to move away from XML towards JSON. That may become HJSON, or some other evolution of JSON, but the direction is quite clear. What we heard from Chaals is the probably move of the Web App/Browser community is to towards a ZIP+JSON manifest combination when it comes to packaging.


> yet figure out what we need in there in terms of concepts and values would be worthwhile regardless of the serialization.
>
> I also like the separation of core terms from publication terms – and possibly even specific publication terms (eg. “Edupub”).
>

+1.

Ivan


> Leonard
>
>
> On 5/29/16, 4:43 AM, "Ivan Herman" <ivan@w3.org<mailto:ivan@w3.org>> wrote:
>
>>
>>> On 27 May 2016, at 20:54, Siegman, Tzviya - Hoboken <tsiegman@wiley.com<mailto:tsiegman@wiley.com>> wrote:
>>>
>>> Hi Ivan,
>>>
>>> Thanks for getting this started.
>>>
>>> What I was envisioning for PWP is something along the lines of exploiting the Navigation Scope [1]. This would mean, that, like an app, a PWP is a defined set of "scope members" [2]. Scope members have many of the same features that we've been discussing for PWP - identity, location, type - and I'm hoping that this can be a launch point for discussion of a customized/customizable equivalent to epub's spine or manifest.
>>
>> I agree. This is certainly one of the items in the manifest doc that we can re-use and keep compatibility. Display mode[1] is another area, for example.
>>
>> However, my problem with the document is more general. Chaals referred to this manifest doc as, possibly, the basis for some sort of a Zip+manifest packaging approach that browsers may favor. However, it is not clear in the document whether, to be a bona fide manifest, it MUST contain all the terms defined in this document (with possibly more via the extension point) or not. And, if not, is there a subset of the terms that is required or is it a completely open set. Because if everything that is in the document is required, then we may run into a problem.
>>
>> Maybe we can agree in some sort of a 'core' set of term for a Web Manifest (and not Web *App* Manifest), which can then be adapted for different constituencies, like Apps or publications, then we would be in a much better place imho.
>>
>> Ivan
>>
>>
>> [1] https://www.w3.org/TR/appmanifest/#the-display-mode-media-feature
>>
>>>
>>> We will have to figure out what to do about all the information, such as installation.
>>>
>>> [1] https://www.w3.org/TR/appmanifest/#navigation-scope
>>> [2] https://www.w3.org/TR/appmanifest/#member-scope
>>>
>>> Tzviya Siegman
>>> Information Standards Lead
>>> Wiley
>>> 201-748-6884<tel:201-748-6884>
>>> tsiegman@wiley.com<mailto:tsiegman@wiley.com>
>>>
>>>
>>> -----Original Message-----
>>> From: Ivan Herman [mailto:ivan@w3.org<mailto:ivan@w3.org>]
>>> Sent: Thursday, May 26, 2016 6:24 AM
>>> To: W3C Digital Publishing IG
>>> Subject: Notes about the Web App manifest document
>>>
>>> Dear all,
>>>
>>> As some sort of a followup from the discussion we had with Chaals… I have looked at the Web App Manifest doc (https://www.w3.org/TR/appmanifest/) to see whether it could work for us as a basis for the manifest in PWP. These are just my (slightly unstructured) notes.
>>>
>>> The document defines a JSON structure/set of terms, and some processing steps to find and consume those manifests. This general approach is identical to what we considered as PWP (or BFM…) manifests, and that is the reason why considering the specification for our purposes is actually important. It includes a number of terms that may be very relevant (e.g., I18N consideration for manifest members like title and descriptions, the concept of display mode which may have a direct relevance for PWP, the concept of a scope, that may define a ‘subset’ of possible URIs to identify PWP resources). It also defines an extension mechanism, i.e., it is possible to define application specific terms (“members”, as they are referred to in the spec), i.e., it is possible to include anything we want for PWP.
>>>
>>> However: the Web App Manifest is, well, Web **App** Manifest. It is geared at Web Applications as far as many of the chosen set of terms are concerned. Its main goal is to define terms needed for the download and installation of Web Applications, i.e., active entities. Although, with a bit of a stretch of imagination, one could consider a PWP an active entity in case the PWP Processor is a downloadable application for that specific content, I am not sure this is the prevalent view. Ie, a PWP is a “passive” thing (regardless of whether it has internal javascript based interactivity) that is downloaded as a set of resources by a general processor. What this means is that the current Web App Manifest contains a bunch of irrelevant terms     (related application, start url, icons, platform).
>>>
>>> There are also terms that, though may look relevant, would probably more appropriate in a CSS file or some other files within the PWP (eg, theme color). The processing/linking is simpler than what we discussed: the only source of a manifest is what can be accessed via a <link> element in HTML, there is no provision for HTTP Return Link Header, or embedded JSON content within an HTML file.
>>>
>>> I am not sure where to go from here. My ideal would be to have a “general” manifest file that would include whatever is generally useful or necessary, a (slightly more general) way of finding a manifest, general processing steps (which are part of the document) and then some clearer extension points/facilities for specific application areas, like Web Apps or PWP.
>>>
>>> Feedbacks? Ideally, we should have some discussion in the IG, ending a more solid, and common view that we could put in as an issue/comment to the current document. With the hope that, via some joint work, we can get somewhere…
>>>
>>> WDYT?
>>>
>>> Ivan
>>>
>>> ----
>>> Ivan Herman, W3C
>>> Digital Publishing Lead
>>> Home: http://www.w3.org/People/Ivan/
>>> mobile: +31-641044153<tel:%2B31-641044153>
>>> ORCID ID: http://orcid.org/0000-0003-0782-2704
>>>
>>>
>>>
>>>
>>
>>
>> ----
>> Ivan Herman, W3C
>> Digital Publishing Lead
>> Home: http://www.w3.org/People/Ivan/
>> mobile: +31-641044153<tel:%2B31-641044153>
>> ORCID ID: http://orcid.org/0000-0003-0782-2704
>>
>>
>>
>>
>


----
Ivan Herman, W3C
Digital Publishing Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153<tel:%2B31-641044153>
ORCID ID: http://orcid.org/0000-0003-0782-2704





--

Bill McCoy
Executive Director
International Digital Publishing Forum (IDPF)
email: bmccoy@idpf.org<mailto:bmccoy@idpf.org>
mobile: +1 206 353 0233<tel:%2B1%20206%20353%200233>




--

Bill McCoy
Executive Director
International Digital Publishing Forum (IDPF)
email: bmccoy@idpf.org<mailto:bmccoy@idpf.org>
mobile: +1 206 353 0233<tel:%2B1%20206%20353%200233>





--

Bill McCoy
Executive Director
International Digital Publishing Forum (IDPF)
email: bmccoy@idpf.org<mailto:bmccoy@idpf.org>
mobile: +1 206 353 0233<tel:%2B1%20206%20353%200233>





--

Bill McCoy
Executive Director
International Digital Publishing Forum (IDPF)
email: bmccoy@idpf.org<mailto:bmccoy@idpf.org>
mobile: +1 206 353 0233<tel:%2B1%20206%20353%200233>




--

Bill McCoy
Executive Director
International Digital Publishing Forum (IDPF)
email: bmccoy@idpf.org<mailto:bmccoy@idpf.org>
mobile: +1 206 353 0233