Re: A followup/writeup on our Monday discussions (was Re: Continuing discussion on Polyfills)

...I'm not taking anything like a strong stance on any of this.  I simply
don't have enough knowledge in this area to assume a strong position, so my
apologies if the following is either repetitive, missing crucial points or
muddying the water.

To comment on and expand on Matt's (and others) thoughts here, I have some
concerns regarding adding unnecessary (which to me translates to
"potentially unused") weight to native browser functionality and making
assumptions regarding what will and what will not be adopted by User
Agents.  This may simply be an indication of my limited knowledge in how
such matters are typically implemented at this level, but in my experience
document customization is the norm rather than the exception. I wouldn't be
surprised if the first thing that were to happen after clearly defining
pagination (as a pretty baseline example) and having a browser adopt
standards and weight for expected pagination behavior is that users will
want publications without pagination.  Or some alternative chunk skipping
pagination, or pagination with a schema that is defined by some alien
numerological schema that arrived to the client in a dream.  Or something
else that we haven't adopted.

I'd prefer the most minimal set of absolute requirements appear in that
form (native to the user agent) and some other solution be found for
"alternative" approaches to affordances.  Clearly polyfill is an unpopular
alternative here, and it may be the only solution is to make the user agent
"publication aware", but I feel a bit like we are asking browsers to become
ePub readers.

Again, I may be entirely missing the point here so I'm presenting this IMHO
as regard MLK (my limited knowledge) only!

Thanks,
Jeff

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 Wed, Feb 7, 2018 at 9:59 AM, Matt Garrish <matt.garrish@gmail.com> wrote:

> > If the fallback is a Web App, it doesn't get in the way.
>
>
>
> But this still requires the user agent to be web publication-aware, at
> least to the extent that it knows to inject the app code when it doesn't
> provide its own interface, no? If it's not, the user doesn't get anything
> (which maybe is life).
>
>
>
> Matt
>
>
>
>
>
>
>
> *From:* Hadrien Gardeur [mailto:hadrien.gardeur@feedbooks.com]
> *Sent:* February 7, 2018 12:05 PM
> *To:* Matt Garrish <matt.garrish@gmail.com>
> *Cc:* Romain <rdeltour@gmail.com>; Ivan Herman <ivan@w3.org>; W3C
> Publishing Working Group <public-publ-wg@w3.org>
> *Subject:* Re: A followup/writeup on our Monday discussions (was Re:
> Continuing discussion on Polyfills)
>
>
>
> > If we don't have information like that available, then it seems like we
> end up in a strange place where we're asking the browser to weed out the
> author-provided interface (it could be done, but is there precedent for
> this?) or we risk overlapping feature deployment.
>
> That's exactly why I think we should absolutely avoid having affordances
> from our publication mode being implemented using a polyfill in individual
> resources.
>
> If the fallback is a Web App, it doesn't get in the way. But if each
> resource in a publication starts implementing affordances from our
> publication mode, it will be nearly impossible for certain user agents (Web
> and native apps) to avoid the kind of overlapping that you're describing
> even with cleanly implemented polyfills.
>

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