Polyfill Standards

[jonathantneal]

Here are my current standards for polyfills. Should we follow this or move forward differently?

---

There are three kinds of polyfills; prolly, pending, proven.

A prollyfill replicates an API that doesn’t yet exist in any browser, but will probably arrive in some browser at a later date. While these kinds of polyfills are rarely linked for middleware implementation, they can still be committed to the source directory.

A rare example of a linked prollyfill is matches().

A pending polyfill replicates an API that is still pending arrival in the target browser, but is already available in some other browser. These kinds of polyfills require feature tests in order to future-proof them against clobbering the eventual, real API.

A theoretical example of a pending polyfill would be String.prototype.contains.

Finally, once an API lands in a stable release of the target browser, we can safely remove feature tests and deliver the proven polyfill to legacy versions of that browser. These are the only kinds of polyfills that can rely solely on the User Agent string.

Most of our polyfills fall into this proven category.

[defunctzombie]

The only thing I would evaluate differently is the idea of inclusion vs exclusion. The current approach of browsers listed in agents.js.json assumes that every other browser not in that lists doesn't need polyfills. We should flip this around to indicate which polyfills are no longer required for a given browser version. Or the alternative is for middleware implementations to just have a way to get "all". An argument for the current approach is that over time the list of polyfills for a browser should go to 0. However, it does mean when a new fill is added, care has to be taken to include it in all the old browser fill lists. So a flip would make the IE list small and the newer browser lists larger (which I am not sure I like). The lists would basically say something like: "we know that for chrome > 1 we don't need these fills. Then for chrome > 4 we don't need these.. so on"

[triblondon]

I'm not sure I buy the argument for 'proven' polyfills. If the user agent is delivering an incorrect user agent string, we still have the possibility of clobbering native APIs by serving unneeded polyfills (as well as the possibility of not delivering polyfills that are actually needed).

Obviously you can't do anything about fixing false negatives, but false positives could surely be easily dealt with by just testing for a native API in all cases.

[triblondon]

Jonathan and I have made peace over this issue (not that we were ever actually at war!) by having feature detects an easy opt in via the query string, both at the feature level and for the whole request. See flags parameter in http://cdn.polyfill.io/v1/docs/api