Re: Continuing discussion on Polyfills

I think there is a fine line between a reading system and a publication.  A print book doesn’t come with a bookmark, it doesn’t give you a pen/pencil to write in the margins, it doesn’t necessarily include a dust jacket, nor does it require one, although it is flexible enough so that libraries can add protective covers as well…

I will even go so far as to say I don’t think pagination is a requirement of a documentation.  At a bare minimum, the consumer should be able to access the content with a level of styling the publisher wishes to add (via CSS).  But, the navigation of the document should be up to the reading system.  There is – in the case of publications – a need for a Next/Previous page, as a document could have a logical reading order.

The web is a pretty amazing place, and I’ve seen what it can do.  From a trade perspective, I’m hard pressed to think of anything that a publications NEEDS and doesn’t have.  As noted previously, from an academic standpoint, there may be some CSS items (complex math) that need more help, but I think of some of the items we’ve talked about - and maybe they don’t belong in a document, but in the reading system as a feature of that system.

To be extremely bold, I will make this statement:
The only item missing from the web today to make a viable web publication is a Canonical Document (Manifest?) that defines the metadata of the document, the resources that make up the document as a whole, and (optionally) a reading order.

If a browser can easily process the above, that’s fine.

Web browsers all implemented Bookmarks and other value-add features of their own into their systems, and we should encourage dedicated ebook reading systems (or widgets/apps if a specific browser is set up for them) to support functionality.

Note on accessibility
In being reductionist, I don’t want to downplay or diminish any of the need for accessibility.  I don’t know enough to know what additional support is needed, but are any of the asks specifically publication-related, or are a publications’ needs for additional accessibility also the needs of the general web.  I assume they would be general, but again, I don’t know.

-Nick

From: Jeff Buehler <jeff.buehler@knowbly.com>
Date: Monday, February 5, 2018 at 1:29 PM
To: "Ruffilo, Nick" <Nick.Ruffilo@ingramcontent.com>
Cc: W3C Publishing Working Group <public-publ-wg@w3.org>
Subject: Re: Continuing discussion on Polyfills

I like this idea at least as a point of reference - something to provide alternative context.

The important question seems to be what the core attributes of a "publication" are, and what the potential hazards of hard wiring solutions in place based on assumptions about that might be.  I don't have answers to that but I tend to be a reductionist in matters like this - less is more, and built up as needed.  Browsers can only support so many native behaviors before they will become mired down under the weight of standards and functionality themselves.  So I'm a little on the fence regarding the idea of turning them into anything like ePub readers, but I'm also opposed to making javascript or any other polyfill solutions mandatory for basic publication behavior and readability.

~J~


Jeffry Buehler

Client Solutions

@learnknowbly<https://twitter.com/learnknowbly/>

kls.knowbly.com<https://kls.knowbly.com>


[https://docs.google.com/uc?export=download&id=1w7ivGFlABV1NMjpW0Ir-yDa-OJbOuL5v&revid=0B690Roiy1-62cEhPa2RSOXBpRml3ejNhc1ZzV0tDbE03amo4PQ]

This message contains information which may be confidential and privileged. Unless you are the addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone the message or any of its contents. If you have received the message in error, please advise by replying to this e-mail and deleting the message.


On Mon, Feb 5, 2018 at 10:16 AM, 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


This message contains information which may be confidential and privileged. Unless you are the addressee (or authorized to receive for the addressee), you may not use, copy or disclose to anyone the message or any of its contents. If you have received the message in error, please advise by replying to this e-mail and deleting the message.