Add a polyfills/transpiler field to the schema

[romainmenke]

If a feature has a known good polyfill, fallback, transpilation, then it can become safe to use / learn much more quickly.

I don't think this should be taken into account when considering if a feature should be in Baseline or not.

I do however think it is valuable to record which features have poyfills, fallbacks,...

MDN already adds links to core-js for some features : https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/at#see_also

---

It might be interesting to do this the other way around.
That polyfills, fallbacks, transpilers advertise which features they support in a format that is compatible with feature set / baseline?

[atopal]

This makes a lot of sense to me. @romainmenke do you have thoughts on how this should be done? Both as represented in the data and in the rules? I'm thinking there are probably degrees of polyfills, some are barely usable, others are as good as the native implementation. Does it matter whether they are being maintained and by whom?

[romainmenke]

I'm thinking there are probably degrees of polyfills, some are barely usable, others are as good as the native implementation.

Indeed very important aspect.

JS

Some problematic things I've seen :

• polyfill doesn't actually work in older browsers (depends on other modern features)
• polyfill was created to demo a proposed feature
• polyfill was created for a specific project and doesn't cover the full specification
• polyfill breaks other native features
• polyfill breaks other polyfills
• ...

A good polyfill must be indistinguishable from the real thing.

For polyfill.io we sometimes rewrite polyfills created by others.
A simplified version of our checklist :

• has at least one browser implementation
• written in es3
• declare all dependencies
• passes as many tests from WPT as possible
• works together with all other polyfills, even unrelated featured
• passes all tests and checks in all browsers currently supported by polyfill.io (IE 9, Chrome 29, Firefox 38,...)

I can't speak for core-js, but @zloirock might be able to add some insights?

CSS

For CSS there is postcss-preset-env which is not a polyfill, because that is impossible in CSS.
Only two things are possible in CSS :

• transpiling to something that works similarly but uses older syntax (e.g. @layer by changing specificity)
• generating fallbacks to different but acceptable values

---

A good JS polyfill will make you project work the same for everyone.

A good CSS transform will make parts of your project "not broken" for everyone.

---

Does it matter whether they are being maintained and by whom

Yes and no.

Who maintains it can be used a proxy for a quality check, but other than that it shouldn't matter. Sometimes the canonical polyfill exists only as a code snippet in MDN docs.

I think listing polyfills can be a nice addition to Baseline, but I don't want this to become a burden.

I don't know what the best approach is here.

---

Both as represented in the data and in the rules

I don't think it should affect rules at first.
I don't want to complicate the definition of Baseline.

To me this is important context, but not a core aspect.

Ideally it would be possible for developers to answer these two questions :

• I want to use feature X, it doesn't pass Baseline 25. Is there a polyfill?
• I am using feature Y with a polyfill. Do I still need this polyfill when targeting Baseline 24?

[dfabulich]

I wish I'd thought harder about this yesterday. IMO this question deeply undermines the idea of a moving/dynamic "Baseline" based on any "simple" criteria.

Today, "Baseline" is based on 2+ major versions (and with some disagreement about what defines "major" e.g. in the Safari case). And maybe we could argue about whether we should count more versions, or switch to a rule based on market share, or whatever.

But if the question we're supposed to be answering is, "Can I use this feature?" and there's a good polyfill or transpiler, then the answer is yes. It doesn't matter how widespread browser support is in that case. You can use it, and your users will be fine.

Indeed, there's a related question, "Can I use this feature safely with progressive enhancement?" There are a number of web features that you really can't use progressively, e.g. novel CSS selectors. You can substitute for them, by manually sprinkling classes around, but you can't just transpile them or polyfill them away.

But most Web API features can be used safely with progressive enhancement. For example, can I use Web Push Notifications? https://caniuse.com/push-api Well, yes. Admittedly, some Safari users can't use them, but your site will work fine even if you can't push notifications to Safari users.

You could imagine trying to define Baseline like this:

• A feature is Baseline if it's supported in 2+ browser versions
• … or if it has a perfect polyfill/transpiler (perfect according to whom?)
• … or if it can be safely feature-detected for progressive enhancement

But this answer is certainly not "simple." (It doesn't really help developers who are having trouble keeping up with evolving web platform features/standards.)

[romainmenke]

Yes, this is why I don't think polyfills/transpilers are relevant to the definition of "Baseline"

But the same aspects, issues, choices that come up around Baseline also apply to polyfills/transpilers, so recording this with feature sets seems valuable to me.

[atopal]

I'd also consider performance as one of the characteristics. CSS can have polyfills, here's one for Cascade Layers, but there are performance issues. Even if you're okay with some degradation, what happens when you stack multiple polyfills?

HTML can have polyfills too, here's one for popover. And this one is already in used in production on at least one major site.

@dfabulich re APIs, that too will be highly specific. In some cases, push messages are nice to have and the site still works well without it, so it's a progressive enhancement, but if you're building a messenger app, that feature missing in Safari iOS is not nice to have, it's a deal breaker.

I also don't think that you'll get away from at least some focus on availability in browsers. Temporal is a polyfill that implements the spec, but the spec keeps changing. Even with an implementation in one browser, the spec cold still change when a second browser starts the implementation and an issue is discovered. Only with two shipping implementations do yo have some reasonable expectation that it won't change (no guarantee), and devs value that stability when they ask "can I use this feature".

Because of all of the above, we left progressive enhancements and polyfills out of the original release of Baseline, but they are real issues, and people care about them. Maybe a definition that takes them into account could be called Mainline :)

[romainmenke]

have polyfills, here's one for Cascade Layers, but there are performance issues.

Curious, I was the main author and it doesn't have performance issues to my knowledge :/

---

But yeah, performance in general is definitely an aspect and would fall under :

A good polyfill must be indistinguishable from the real thing.

[atopal]

My apologies, I was thinking of the Container Queries polyfill.

[romainmenke]

At this time I think this is a bit of a tangent and that it can be closed.

Anyone can annotate their polyfill to be a polyfill for a specific web feature defined in this project. I think that is a more interesting first step.

[ddbeck]

At this time I think this is a bit of a tangent and that it can be closed.

Anyone can annotate their polyfill to be a polyfill for a specific web feature defined in this project. I think that is a more interesting first step.

Thanks, Romain. I think it's a good idea to have polyfill authors refer back to features, rather than the other way around (at least for now). This is also likely to get easier as we cover more of the platform. I'm going to close this, but feel free to request to reopen or file a new issue if there's something new to cover here.

(see also #1708)