Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Browser support à la autoprefixer #32

Closed
MoOx opened this issue Sep 19, 2014 · 13 comments
Closed

Browser support à la autoprefixer #32

MoOx opened this issue Sep 19, 2014 · 13 comments

Comments

@MoOx
Copy link
Owner

MoOx commented Sep 19, 2014

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
Copy link

+1

1 similar comment
@AntonTrollback
Copy link

+1

@MoOx MoOx modified the milestones: v2.0.0, v1.0.0 Dec 1, 2014
@MoOx MoOx mentioned this issue Dec 1, 2014
@MoOx
Copy link
Owner Author

MoOx commented Dec 3, 2014

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
Copy link
Owner Author

MoOx commented Dec 3, 2014

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
Copy link
Owner Author

MoOx commented Dec 4, 2014

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
Copy link
Owner Author

MoOx commented Dec 4, 2014

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
Copy link
Owner Author

MoOx commented Dec 9, 2014

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

@MoOx
Copy link
Owner Author

MoOx commented Dec 11, 2014

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

@MoOx
Copy link
Owner Author

MoOx commented Dec 15, 2014

browserslist & caniuse-api are ready. Will integrate that asap.
Thanks @ai & @Nyalab for thoses modules.

@Nyalab
Copy link
Contributor

Nyalab commented Dec 15, 2014

this will be awesome when you will have integrated those tools, keep up the good work man!

@MoOx
Copy link
Owner Author

MoOx commented Dec 15, 2014

YOU FEEL 1.0.0, DO YOU?

@MoOx
Copy link
Owner Author

MoOx commented Feb 3, 2015

FYI, this is done and ready.
But I need to fix this issue Nyalab/caniuse-api#18 in order to have a browserify build that works (for the playground).

@Nyalab
Copy link
Contributor

Nyalab commented Feb 3, 2015

I take care of that very soon 😸

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants