-
-
Notifications
You must be signed in to change notification settings - Fork 188
Browser support à la autoprefixer #32
Comments
+1 |
1 similar comment
+1 |
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. Maybe we should act more like a huge fallback instead of "just" a replacement? |
FYI, custom props & calc have a preserve options to keep original code & just prepend fallbacks. We can add the same behavior for every features. |
This option will only make sense for low simple standalone features that cannot affect the entire stylesheet (eg: all functions & stuff like rebeccapurple). 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. |
That also a reason why I think cssnext should be like autoprefixer: adding code instead of doing some brutal replacement. |
FYI, here is a start from @Nyalab |
For now @Nyalab package is doing the opposite of what we want. I think from this issue we will have something interesting soon |
browserslist & caniuse-api are ready. Will integrate that asap. |
this will be awesome when you will have integrated those tools, keep up the good work man! |
YOU FEEL 1.0.0, DO YOU? |
FYI, this is done and ready. |
I take care of that very soon 😸 |
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
The text was updated successfully, but these errors were encountered: