MDN Browser Compatibility Data

[jonathantneal]

I need to use mdn’s browser compatibility data to properly support features in PostCSS Preset Env. I would like to use browserslist alongside browser-compat-data, but I’m unsure the best way to accomplish this.

Could there be a guide or new feature that would allow me to use browserslist with mdn browser-compat-data?

While caniuse or cssdb often divide features by specification, actual browsers implementations are far more nuanced. In the case of CSS Logical Properties and Values, there have been 9 partial implementations unevenly spread between browsers, and there will be more implementations as the remaining features are implemented. That doesn’t include additional updates for browser bugs or spec revisions.

Now, I have a separate but related issue that caniuse is giving fully-implemented green to browsers with incomplete implementations (example: CSS Logical Properties and Values), but it brings me to an important point. browser-combat-data is granular by nature. I am able to get support data for specific properties or property value combinations. For most PostCSS polyfills, this is exactly what I need.

My ideal setup would be statcounter for browser usage statistics (this is what caniuse uses), browser-compat-data for feature implementation status, and cssdb/w3c for spec stability status.

[ai]

I would like to use browserslist alongside browser-compat-data, but I’m unsure the best way to accomplish this.

I do not the best way too :). I think nobody has relevant experience. So you need just try to do it.

I think the main problem is to convert Can I Use browsers to browser-compat-data. I think we can do it with simple function.

I am closing this issue, feel free to open it on any additional question or if you will need anything from Browserslist.

[jonathantneal]

So you need just try to do it.

I have tried and I am trying. I created an issue because it is tied to a real need and I need more brains on this.

I think the main problem is to convert Can I Use browsers to browser-compat-data. I think we can do it with simple function.

Yes, the best thing I have come up with is to use browserslist to parse a user’s configuration and then parse browser-compat-data and transform it into something compatible with browserslist, and then run another function to compare the two. However, that function only starts simple, and it gets more complicated to map out specific sets of browser data and transform the list into the browserslist format. All together, to copy this function and the mdn dependency consistently across 20+ projects basically become me writing another tool to sit atop browserslist.

If that’s what it takes — okay — but I’m not looking forward to it.

[antross]

@jonathantneal Not sure if this fits what you need, but we recently did something similar for webhint. We ended up with a couple of utilities to help query browser-compat-data which includes a browsers helper that has a simple map of caniuse browser names to MDN ones.

Currently this is used by some slightly higher-level helpers for querying MDN data in the compat portion of our @hint/utils package. We're also exploring whether those higher-level helpers may be useful as part of browser-compat-data directly.

[ben-eb]

The problem is browserslist uses a much richer data set via caniuse than browser-compat-data; for instance caniuse correctly identifies that the unicode-range descriptor is only partially supported in IE, whereas browser-compat-data tells us that the feature is supported since IE9. On the flip side caniuse does miss some areas e.g. :host but they are available in the MDN data.

So I'm not sure if there's a way to possibly fuse together the two data sets automatically whilst keeping this nuance. It's certainly a lot of work nonetheless.

[jonathantneal]

@ben-eb, thanks for those examples. They are really valuable to see how either the caniuse tap or mdn tap may get a thing right that the other does not. I think this is a good reason to allow the user to configure the source of truth.

It’s worth noting that, to the best of my knowledge, information from caniuse and browser-compat-data are freely provided by contributors of unknown numbers and unknown longevity. In the case of desktop user/browser stats, this information comes from statcounter. In the case of mobile usage/browser stats, only caniuse provides this, and we’re not told where the data comes from or how it is extrapolated. In any case, I consider it part of my duty to avoid incorrectly overstating compatibility in one browser or another, as it contributes to a bias in developers that one browser is worth supporting over another.

Next; I’m still considering a strategy like @antross has taken. My main hangups with that solution are:

1. I forward the caniuse browser bias to browser-compat-data (e.g. the now deprecated Edge Mobile remains an unsupported query). Maybe it’s a non-issue, but I take seriously denying access to any browser dataset as a form of gatekeeping that I want no conscience part in.
2. I potentially require each plugin or preset-env to manage updates to browser-compat-data, or the user to add the configuration themselves. Perhaps there is a reasonable solution to this issue.

[socketpair]

Please reopen!

I want to limit browsers using supports mdn-javascript_builtins_promise_allsettled for example.

[ai]

@socketpair open a separated issue

[socketpair]

@ai #522