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

Continuing discussion on Polyfills

From: Ruffilo, Nick <Nick.Ruffilo@ingramcontent.com>
Date: Mon, 5 Feb 2018 18:16:03 +0000
To: W3C Publishing Working Group <public-publ-wg@w3.org>
Message-ID: <FDFCEFEE-7C7F-4D04-9F4D-4DFB6935FB16@ingramcontent.com>
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.

Received on Monday, 5 February 2018 18:17:12 UTC

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