Re: Continuing discussion on Polyfills

Nick,

I agree that, for some tasks, a server side processing (let us not called that a polyfill, that term is reserved for client side processing) can and should be used. But, in some sense, that is hidden for us, and it should be. What counts for us is, essentially, what comes down the wire; in some sense this is the only aspect that counts on the Web. What happens on the server is a matter of the publishing workflow, and this is not something we are dealing with (at least not in this WG).

On a more pragmatic level: using and installing a server side processing is not at the disposal of most people. It may need special authorization, access to server parameters, whatever: relying on those would make it impossible for many to publish simple publications.

Sigh…

Ivan

> On 5 Feb 2018, at 19:16, Ruffilo, Nick <Nick.Ruffilo@ingramcontent.com <mailto:Nick.Ruffilo@ingramcontent.com>> wrote:
> 
> W3C Publishing Group,
> 
> From our discussion today about if the polyfill should exist within a document (that would allow the document to be read), what I am proposing – and will build by next week – is a server-side mechanism that would allow a document to have polyfills ADDED to the document in real-time when readed.  This would allow:
> 
> 1)       A web publication to exist without any polyfills at time of creation.
> 2)       Easy updating of polyfills as support for new features becomes available.
> 3)       Addition of custom polyfills for a server that wished to support additional features (such as math formatting, etc)
> 
> Web publications will need to live on the web, on a server, so it’s completely reasonable to have a server-side extension to handle such content.  Additionally – one server-side extension can support an unlimited number of documents.  When it comes to back-end technology, there are a limited number of technologies that an extension would need to be written for to cover all bases.
> 
> The purpose and goal would be to take something like an (unzipped) epub and to give it a basic display on the web.  Then the question comes – what are the basic requirements of a reading system that the web does not support.  If an epub can be opened and read, but bookmarks cannot be created/stored, it might be better to have that feature supported by a free/paid app in the extensions store (physical books do not come with bookmarks included, you have to modify the book (fold the page) or get a bookmark – which is an external object.)
> 
> I will admit, my expertise comes mainly from trade publishers, and boiled down, the needs seem to be:
> 1)       A user can EASILY and enjoyable read my ebook
> 2)       My ebook can be styled to look great to an overwhelming majority of my readers
> 3)       I can sell my ebook
> 4)       I can create my ebook with relative ease
> 5)       If my book is on the web, I’d like some controls over who can access it.
> 
> Some of these things – such as selling and access control go beyond our specs, but can be solved with current web technologies (no need for DRM if you use something like htaccess passwords or some other login mechanism to control access to a set of files).  Most publishers are creating EPUBs so creating a web-friendly (HTML/CSS) document should not be a far throw, and tools will catch up.
> 
> As time goes on, if browsers want to implement pagination, document stitching, multi-document searching, etc, that is awesome, the server-side script can then have a smaller footprint.
> 
> -Nick


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