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

Hi Jimini,

> On 7 Feb 2018, at 13:38, Jiminy <jiminy@chapalpanoz.com <mailto:jiminy@chapalpanoz.com>> wrote:
> 
> From the Web Dev point of view, the following item sounds backwards to me:
> 
>> A publication MAY use a reference to a Javascript application (let us call it a WP Script) that implements a (minimally viable) publication mode on top of the OWP, and which MAY be used as a fall-back if the User Agent does not have such a mode built in.
> 
> Mind you, I understand that it may be necessary to explicitly tell that so that it can serve as a green light to publishers. However, it is pretty expected that proly-, pony-, poorly, polyfills (you name it) will exist. Also, there is a nomenclature about that (https://www.w3.org/2001/tag/doc/polyfills/#nomenclature-what-is-a-polyfill- <https://www.w3.org/2001/tag/doc/polyfills/#nomenclature-what-is-a-polyfill->) and WP Script feels like trying to reinvent yet another term the web won’t understand.
> 

I must admit I'm not sure I fully understand what you say.

- The term "WP Script", in my mind, is just a name I use to designate a script whose goal is to implement a minimal viable publication mode. And to differentiate it from another script that may do some publication specific interaction like visualizing some research data. The term does not refer to any particular architectural approach as for how it does it, whether it is a polyfill in the sense you refer to, or any other means that I do not know about (I admit not having a really good experience in that level of programming and development). I actually do not think it is our job to define how that stuff should be implemented, we would only define the affordances that are to be performed based on the data that the manifest provides. Obviously, we have to have existence proofs that such implementations are possible. I do not think this tries to reinvent the wheel.

- The on/off switch that you refer to below is an action on the user agent's side. If the same WP is interpreted by a (future version of) iBooks, Readium app, or Google Play, those user agents have the possibility to ignore that script altogether. A future version of MS Edge or Google Chrome might also decide to do the same because they have a built in publication mode.

If we are on the same line here, I wonder how to make this message clearer in the text…

Ivan



> It may well be orthogonal to the working group (although it’s best practice editors take feedback from polyfills authors to improve the specs, cf. https://www.w3.org/2001/tag/doc/polyfills/#advice-for-spec-editors <https://www.w3.org/2001/tag/doc/polyfills/>) but isn’t orthogonal to its members. A few examples:
> 
> When Adobe pushed for CSS Regions (which they implemented themselves in Webkit by the way), they also provided authors with a polyfill: https://github.com/adobe-webplatform/css-regions-polyfill <https://github.com/adobe-webplatform/css-regions-polyfill>
> 
> Google is currently pushing for Web Components, and if you take a look at the Web Components project, whose aim is to “be a long-term project committed to making the web better by sharing peer-reviewed custom elements that are usable across all browsers, and interoperable with existing libraries”, which implies polyfills have to be developed (https://www.webcomponents.org/polyfills/ <https://www.webcomponents.org/polyfills/>), they dedicate resources to that project (see the number of Googlers participating to this project: https://github.com/orgs/webcomponents/people <https://github.com/orgs/webcomponents/people>).
> 
> Polyfills are everywhere, they’re an essential part of the process of extending the web. You have services providing feature detection like Modernizer (https://modernizr.com <https://modernizr.com/>), The Financial Times running https://polyfill.io/v2/docs/ <https://polyfill.io/v2/docs/>, CSS polyfilling made easy (https://philipwalton.github.io/polyfill/ <https://philipwalton.github.io/polyfill/>) – although the library is no longer supported because polyfilling CSS is extremely nasty and CSS Houdini is currently designed to address this problem, and so on and so forth.
> 
> Some things can’t be polyfilled, but stuff that can be will be, because people don’t wait for a feature to be implemented in every browser anymore.
> 
> - No hyphens, no problem: https://github.com/mnater/Hyphenator <https://github.com/mnater/Hyphenator>
> - IE and Edge < 16 don’t support object-fit? No problem: https://github.com/constancecchen/object-fit-polyfill <https://github.com/constancecchen/object-fit-polyfill>
> - We need service worker, let’s make a polyfill: https://github.com/dominiccooney/cache-polyfill <https://github.com/dominiccooney/cache-polyfill>
> - So iOS doesn’t support the WAM? Let’s try to polyfill it: https://github.com/firtman/iWAM <https://github.com/firtman/iWAM>
> 
> More importantly, from the Polyfills best practices, again (https://www.w3.org/2001/tag/doc/polyfills/#advice-for-spec-editors <https://www.w3.org/2001/tag/doc/polyfills/#advice-for-spec-editors>), you have to “ensure that the feature exposes detection hooks that can be effectively used by feature-detection code to determine whether a user agent offers a native implementation of the feature.” What this means in the polyfill context is that the feature can be detected in JavaScript, see this file for an example (https://github.com/Modernizr/Modernizr/blob/master/src/computedStyle.js <https://github.com/Modernizr/Modernizr/blob/master/src/computedStyle.js>). Basically, polyfills authors should be able to do the following:
> 
> if ('feature' in window) {
>   // do nothing
> } else {
>   // polyfill
> }
> 
> Problem is implementations can be partial (browser A only supports part of the spec, which doesn’t include pagination but all other features), may diverge (browser B offers 12 user settings while browser C offers only 6), etc. So a global flag is a terrible idea, because you may need to polyfill parts which haven’t been implemented yet by browser A, and add some settings, related to a11y for instance, in browser C.
> 
> What this means is that nobody wants to end up with Reader Mode currently offers:
> 
> 1. authors are clueless: https://stackoverflow.com/questions/2999600/how-to-disable-safari-reader-in-a-web-page <https://stackoverflow.com/questions/2999600/how-to-disable-safari-reader-in-a-web-page> + https://stackoverflow.com/questions/31295693/how-to-tell-microsoft-edge-what-it-should-display-in-reading-mode <https://stackoverflow.com/questions/31295693/how-to-tell-microsoft-edge-what-it-should-display-in-reading-mode>
> 2. APIs (add-ons, apps, etc.) are browser-specific: https://developer.apple.com/library/content/documentation/Tools/Conceptual/SafariExtensionGuide/WorkingWiththeReader/WorkingWiththeReader.html <https://developer.apple.com/library/content/documentation/Tools/Conceptual/SafariExtensionGuide/WorkingWiththeReader/WorkingWiththeReader.html> + https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/tabs/toggleReaderMode <https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/tabs/toggleReaderMode>
> 3. there is no standard, nobody can tell exactly what’s a reader mode from any spec, there is consensus between vendors but no control
> 4. feature detection is impossible (https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Feature_detection <https://developer.mozilla.org/en-US/docs/Learn/Tools_and_testing/Cross_browser_testing/Feature_detection>)
> 
> Finally, vendors have limited resources, and polyfills serve as a clue when it comes to prioritizing implementations, but authors must also make their request heard (https://developer.microsoft.com/en-us/microsoft-edge/platform/status/?q=sort%3AVotes <https://developer.microsoft.com/en-us/microsoft-edge/platform/status/?q=sort%3AVotes>), and sometimes it takes doing/funding the implementation yourself (https://www.igalia.com/nc/igalia-247/news/item/shipping-css-grid-layout-in-major-browsers/ <https://www.igalia.com/nc/igalia-247/news/item/shipping-css-grid-layout-in-major-browsers/>) because it is not a priority for the core dev team (http://www.chriskrycho.com/2017/chrome-is-not-the-standard.html <http://www.chriskrycho.com/2017/chrome-is-not-the-standard.html>).
> 
> So to sum things up:
> 
> - polyfills will be needed;
> - authors should be able to detect features, using the “standard” mechanism (any other will end up isolating Web Publications);
> - it mustn’t be an on/off trigger;
> - polyfills can be hugely beneficial in helping to roll out a feature
> - new web features need not be constrained by the need to enable polyfill implementations. However, all other things being equal, choosing a design that is more polyfill friendly is desirable.
> - the web has been managing this for years, there are best practices available (https://www.w3.org/2001/tag/doc/polyfills/ <https://www.w3.org/2001/tag/doc/polyfills/>), don’t try to reinvent the wheel.
> 
> I’m sorry for this long mail but agree with Nick Ruffilo there. The importance of this discussion can’t be understated, I’m pretty concerned by its developments since polyfills are hugely important to new features.
> 
> Best,
> 
> --
> Jiminy
> 
> Le mercredi 7 février 2018 à 12:14, AUDRAIN LUC a écrit :
> 
>> Thanks Ivan,
>> I find it very helpful.
>> It should help newbies to understand what we plan to do.
>> It certainly will help me explain it more easily to publishers outside our
>> involved circle.
>> Bets,
>> Luc
>> 
>> 
>> 
>> Le 07/02/2018 09:22, « Ivan Herman » <ivan@w3.org <mailto:ivan@w3.org>> a écrit :
>> 
>>> Dear all,
>>> 
>>> I have been trying to put down some "principles", general statements,
>>> that could summarize both the discussions on Monday and also some of the
>>> ideas in this thread. It certainly helped me, and maybe it is helpful for
>>> others, too. I am not sure, if we have a consensus on the content,
>>> whether these are principles we would put into the WP document (it may be
>>> too much, but I trust more Matt to give a guidance on this) or whether it
>>> would just be put as a document to our Web sites so that we can refer to
>>> them.
>>> 
>>> Most of the content are not my own. It is an attempt to distill a
>>> possible consensus. It is my secret hope that it would also be a good
>>> basis for an answer to questions like the one coming from the TAG.
>>> 
>>> I have put this on a Github Wiki page, so that we can all easily comment
>>> on it and possibly edit it. Here it is:
>>> 
>>> https://github.com/w3c/wpub/wiki/WP-Principles <https://github.com/w3c/wpub/wiki/WP-Principles>
>>> 
>>> Does this help?
>>> 
>>> Cheers
>>> 
>>> Ivan
>>> 
>>> ----
>>> Ivan Herman, W3C
>>> Publishing@W3C Technical Lead
>>> Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
>>> mobile: +31-641044153
>>> ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>


----
Ivan Herman, W3C
Publishing@W3C Technical Lead
Home: http://www.w3.org/People/Ivan/ <http://www.w3.org/People/Ivan/>
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704 <http://orcid.org/0000-0003-0782-2704>