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


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> 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.