-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Add a polyfills/transpiler field to the schema #189
Comments
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? |
Indeed very important aspect. JSSome problematic things I've seen :
A good polyfill must be indistinguishable from the real thing. For
I can't speak for CSSFor CSS there is
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.
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.
I don't think it should affect rules at first. To me this is important context, but not a core aspect. Ideally it would be possible for developers to answer these two questions :
|
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:
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.) |
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. |
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 :) |
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 :
|
My apologies, I was thinking of the Container Queries polyfill. |
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) |
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_alsoIt 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?
The text was updated successfully, but these errors were encountered: