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

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-) and WP Script feels like trying to reinvent yet another term the web won’t understand.  

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

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/), they dedicate resources to that project (see the number of Googlers participating to this project: 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), The Financial Times running https://polyfill.io/v2/docs/, CSS polyfilling made easy (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
- IE and Edge < 16 don’t support object-fit? No problem: https://github.com/constancecchen/object-fit-polyfill  
- We need service worker, let’s make a 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

More importantly, from the Polyfills best practices, again (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). 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/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.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)  

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), 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/) because it is not a priority for the core dev team (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/), 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
> >  
> > Does this help?
> >  
> > Cheers
> >  
> > Ivan
> >  
> > ----
> > Ivan Herman, W3C
> > Publishing@W3C Technical Lead
> > Home: http://www.w3.org/People/Ivan/
> > mobile: +31-641044153
> > ORCID ID: http://orcid.org/0000-0003-0782-2704
> >  
>  
>  
>