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

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