Re: Continuing discussion on Polyfills

Ivan,

100% agree – it’s orthogonal and not the concern of the working group – but it’s for that exact reason that I think it IS extremely valuable to the working group.  If a relatively technical solution can be supplied that solves a great deal of problems, that can be used as a path forward for publishers that does not mean waiting a long time for browsers to implement things.

It also means that a service provider could have a solution available with relative ease to support WPs.  If no one supports WPs, no one will make them.  Then, we can look and say: “Here’s what this new tool is missing” or “here’s what we think needs more control” etc.

Nonetheless, I’ll be making this thing and people can play with it starting next week.

-Nick

From: Ivan Herman <ivan@w3.org>
Date: Tuesday, February 6, 2018 at 11:08 AM
To: Benjamin Young <byoung@bigbluehat.com>, "Ruffilo, Nick" <Nick.Ruffilo@ingramcontent.com>
Cc: Hadrien Gardeur <hadrien.gardeur@feedbooks.com>, Jeff Buehler <jeff.buehler@knowbly.com>, Deborah Kaplan <deborah.kaplan@suberic.net>, Tzviya Siegman <tsiegman@wiley.com>, W3C Publishing Working Group <public-publ-wg@w3.org>
Subject: Re: Continuing discussion on Polyfills




On 6 Feb 2018, at 16:50, Benjamin Young <byoung@bigbluehat.com<mailto:byoung@bigbluehat.com>> wrote:

Nick,

What you've described so far sounds a lot like a static site generator, such as Jekyll: https://jekyllrb.com/


… which we also use for the WG's home page:-)



Authors write simple (stupid) content-centric document (typically Markdown) and organize them into a certain structure and then the tooling does the rest (outputs HTML, adds scripts and polyfills, etc).

One such static site generator that does all kinds of book-ish things is https://www.gitbook.com/


Their tooling is open source https://github.com/GitbookIO/gitbook (Apache License 2.0) and can be used to generate PDFs, EPUBs, sites, etc.

Is what you're proposing essentially this same idea?

While this is indeed important and useful, I am not sure this is a topic of this working group. Just as the EPUB standard does not care whether the content is created on-the-fly somewhere, the same holds for the WP…

Nick,  I think I understand what you mean: the server expands the simple HTML content by adding a reference to a script in the fly. Which is perfectly fine, and may be a good solution for deployment for publishers, but it is again orthogonal to the concerns of this Working Group imho…

Ivan




Cheers,
Benjamin
--
http://bigbluehat.com/

http://linkedin.com/in/benjaminyoung

________________________________
From: Ruffilo, Nick <Nick.Ruffilo@ingramcontent.com<mailto:Nick.Ruffilo@ingramcontent.com>>
Sent: Tuesday, February 6, 2018 9:56:02 AM
To: Hadrien Gardeur; Jeff Buehler
Cc: deborah.kaplan@suberic.net<mailto:deborah.kaplan@suberic.net>; Siegman, Tzviya - Hoboken; W3C Publishing Working Group
Subject: Re: Continuing discussion on Polyfills

I like the way this is presented and said.


Responding to a previous note from Ivan – When I was talking about Polyfills, I was not referring to anything on the back-end.  What I was recommending is that a back-end script is what injects any polyfills into the documents.  Once I have the example, it will be more clear.


And while everyone might not have access to a customizable server, I promise you that if there is value – services will pop up to make it easier.  When the web first started, servers were expensive, but services like Geocities gave you a small chunk of space on their servers so you could get started.  Publishing is not easy, and that’s OK.  I believe we need to focus on making the overall process as Logical, accessible, and future-proof as possible.


As for all the Accessibility feedback – thank you.  I hear it loud and clear.


-Nick


From: Hadrien Gardeur <hadrien.gardeur@feedbooks.com<mailto:hadrien.gardeur@feedbooks.com>>
Date: Tuesday, February 6, 2018 at 4:33 AM
To: Jeff Buehler <jeff.buehler@knowbly.com<mailto:jeff.buehler@knowbly.com>>
Cc: "deborah.kaplan@suberic.net<mailto:deborah.kaplan@suberic.net>" <deborah.kaplan@suberic.net<mailto:deborah.kaplan@suberic.net>>, "Siegman, Tzviya - Hoboken" <tsiegman@wiley.com<mailto:tsiegman@wiley.com>>, "Ruffilo, Nick" <Nick.Ruffilo@ingramcontent.com<mailto:Nick.Ruffilo@ingramcontent.com>>, W3C Publishing Working Group <public-publ-wg@w3.org<mailto:public-publ-wg@w3.org>>
Subject: Re: Continuing discussion on Polyfills


IMO we should separate things on the authoring side from the user agent side.

Authoring

A Web Publication MUST be entirely readable without any kind of polyfill, extension or specific browser support.
This means that all resources should be reachable through navigation, ideally in a sequence that follows the reading order.

For every other affordance (I'm working on those in the lifecycle branch<https://github.com/w3c/wpub/pull/130>), the author MAY attempt to support them from the entry page (HTML document returned by the WP address). This can be achieved by pointing to a Web App from that page.


User agent


A WP aware user agent SHOULD enhance the experience of reading a Web Publication by providing additional affordances that won't clash with the author's intent (easier said than done, user settings for example are very difficult to handle).


IMO, presentation and navigation affordances MUST only enhance resources that are within the scope of the WP which means:

  *   all resources listed in the default reading order and list of resources
  *   but this excludes the entry page or any other resource not listed in our collections
For resources that are not within the scope of a WP, a user agent MAY provide two other affordances instead:

  *   switch to publication mode
  *   add to the list of publications


----
Ivan Herman, W3C
Publishing@W3C Technical Lead
Home: http://www.w3.org/People/Ivan/

mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704