Browser support à la autoprefixer

[MoOx]

Using a list of browser version we should be able to enable/disable a feature.
Note: some feature might require some other (eg: if custom props are disabled (untouched), but color enabled, var() in color() won't be resolved & browser wont be able to resolve it too since color is unsupported (in this case)). Not sure this can happen, we will see how browsers implement stuff :/

Ref postcss/autoprefixer#284

[mahnunchik]

+1

[AntonTrollback]

+1

[MoOx]

If for example vars are implemented before other functions we will face a real problem because we won't be able to add fallbacks for new functions without hardcoded values.
custom props are important deal.

Maybe we should act more like a huge fallback instead of "just" a replacement?

[MoOx]

FYI, custom props & calc have a preserve options to keep original code & just prepend fallbacks. We can add the same behavior for every features.

[MoOx]

This option will only make sense for low simple standalone features that cannot affect the entire stylesheet (eg: all functions & stuff like rebeccapurple).
Vars will always be a major feature since if you disable it (imagine it's supported in your browser scope) you will still have color(var(--blah)...) that we wont be able to resolve.

That being said, I'll still try to implement that for some features when it can be done. This will need to be clear in the documentation.

Will investigate about reusing what autoprefixer is using to make a standalone module that will be integrated here.

[MoOx]

That also a reason why I think cssnext should be like autoprefixer: adding code instead of doing some brutal replacement.
Anyone have opinion about that approach?

[MoOx]

FYI, here is a start from @Nyalab
https://github.com/Nyalab/caniuse-api
And here is something that would make us happy MoOx/caniuse-api#3

[MoOx]

For now @Nyalab package is doing the opposite of what we want.

I think from this issue we will have something interesting soon
postcss/autoprefixer#284