With @sashko we talked about an idea that Meteor could use autoprefixer by default on all CSS to add vendor prefixes to CSS. What people think? Would this be a good feature? Are there issues people perceive if this would go through?
2 Likes
Personally, not a fan to enforce it. Via package, sure. If default and not possible to disable: Please no.
I’m currently building a css framework with evergreen support in mind -> Where vendor prefixes don’t matter that much anymore. Amongst others I’m trying to get rid of the compile step with that framework.
This also relates to houdini, which will enable us to write our own css rules in the future, meaning vendor prefixes won’t be necessary anymore. With that in mind, having vendor prefixes only bloats the codebase and in many cases is no longer necessary unless you still support Internet Explorer. The entire framework is barely 20kb right now and works in every modern browser and only uses a prefix where absolutely necessary. With prefixes it easily becomes 40kb – something I want to avoid.
With that said: As an option why not 
?
Of course you could configure it.
The better option will be proper PostCSS support which is almost impossible right now 
2 Likes
Edit. Confused autoprefixer with this package https://atmospherejs.com/seba/minifiers-autoprefixer is that what is becoming proposed?
Problem with my package and the postcss package (which is similar), is that it only runs in the minification step. So it does not work during development and on css that has been imported through javascript.
That’s why I think @mitar suggests having it by default on all css.
The current way is broken in many ways, but I don’t know if having it by default is a good idea.
3 Likes
I would definitely appreciate a proper auto-prefixer solution in Meteor. Currently, I’m using fourseven:scss together with seba’s package, but as he describes, this is a workaround solution. Would be great if Meteor would just support any CSS post-processor. It’s really sad that it is so hard to use stuff like SCSS, Compass and Post Processing in Meteor.
2 Likes
My impression was that using SCSS is quite easy - not PostCSS though, I agree.
We were thinking that, similar to how Meteor apps start with ecmascript for ES2015 by default, we could have PostCSS on by default with a standard set of plugins. But I can see from the responses that perhaps a more configurable build pipeline is more useful for advanced developers.
Yeah, I know that Meteor needs many other important improvements, but the build system is a big week point for me. Full and configurable PostCSS support and full CSS Modules support would be awesome, or at least full support for Webpack as an option
One of the big struggles I’ve run into with this topic is that you can’t use tools like Autoprefixer on CSS that has been imported by a JS file (yes, I know it was mentioned above). Most people I’ve talked to about it usually say “ok, then just import those styles from a CSS file”. And sure, that’s occasionally fine. But we have a use case where we need to have a module that’s entirely inside a lazily loaded directory (imports) and it needs to have a single JS entry point. That single import point works fine to import all JS and CSS inside the module, but there’s no way to autoprefix the styles without importing the CSS in that module from another CSS file outside of that module. So the single JS import point with autoprefixed CSS isn’t currently possible unless I process the CSS manually first.
Obviously, it’s the same thing if you want to import styles from an npm module. To be fair, those are usually processed already, so it’s admittedly less of an issue there. But still.
So, does anyone know if there’s at least some kind of hack I can pull off with JS to prefix/process styles that are imported from JS files? I feel like someone has to have solved that by now - even if it’s a total hack solution.
Sorry to bump a topic that much old. But has anyone found a solution to this issue yet ?
(Autoprefix and miny styles imported in js file)