Port to PostCSS

[mttmccb]

Feel free to shoot me down but I'd love to see a PostCSS version as I believe it has a bit more flexibility than SASS. I've seen other project support multiple pre-processors (SASS and LESS or SASS and Stylus) in the past by having a separate folder and having a toggle in the build.

Thoughts?

[andrewtpoe]

I vote for keeping Blaze in sass, or at least keeping a version in sass. It makes importing into Rails very simple. When importing the raw sass files I can also customize the theme directly from the asset pipeline with a single file. As I understand it now, this would become significantly more complicated with Post CSS.

[mttmccb]

I've had a go at converting it but either my PostCSS or SASS isn't up to scratch. It was a slightly brute force attack of

• copy the scss folder
• copy and update the gulp task so there's a postcss build
• rename all the files
• throw PostCSS plugins at it to process it

I'll keep trying :)

I don't use Rails so I can't comment on what impact it might have.

[gregorypratt]

Wouldn't this be enough?

https://github.com/postcss/gulp-postcss#passing-additional-options-to-postcss

[mttmccb]

Sadly not, but it's a good starting point

[gregorypratt]

What are the benefits of PostCSS?

[mttmccb]

The biggest is the flexibility and the ability to add plugins to do additional things not possible with SASS. Ashley Nolan wrote a good post on it. For example postcss-style-guide might help with #130.

The down sides are the syntax is a little different and it seems somethings aren't possible in the same way as SASS. I'm still working on the conversion to see what's involved before I try additional plugins to improve it.

[mttmccb]

I got quite far on converting it but got a little stuck on colours as there doesn't seem to be an easy way to convert from sass to the standard.

[Kurre]

Personally I'd love to see a PostCSS version of BlazeCSS. We currently use PostCSS in our big project and I absolutely love it. And we have noticed that mixin a Sass vendor packages to our own PostCSS files isn't always fluent as possible 😄 (compile Sass files into a /vendor and import those files to our css).

I can't really comment on the PostCSS benefits over Sass, since I've never really used Sass in it's full extent. Most of the stuff can be done with both and many PostCSS plugin features/ideas are coming from Sass land.

For me, one big advantage was the compiling speed..my dev-machine isn't so fresh anymore and where simple Sass files took around 3-4s to compile, PostCSS does the same in a fraction of second. It really helps when you don't need to wait Sass to compile, but the changes in sources come out almost instantly. (using browser-sync etc..)

There's also a myriad of plugins which you can use to transform your CSS. Most popular is probably http://cssnext.io which offers a nice set of features in one package. More nice plugins can be found from http://postcss.parts.

PostCSS also gives you a chance to do many things which aren't possible with current preprocessors (afaik, don't trust me on this one 😄). Like processing files/urls/images/links/fallbacks/mediaqueries/etc..without doing some big mixins to handle those situations.

Something like: https://github.com/TrySound/postcss-inline-svg https://github.com/ben-eb/postcss-normalize-url https://github.com/ben-eb/cssnano/blob/master/package.json https://github.com/anandthakker/doiuse https://github.com/assetsjs/postcss-assets https://github.com/hail2u/node-css-mqpacker https://github.com/hudochenkov/postcss-sorting https://github.com/postcss/autoprefixer (everybody uses this already anyway 😄)

Some other cool plugin(s) to mention: https://github.com/peterramsing/lost

What comes to porting Blaze to PostCSS, imho it won't be a walk in the park. Compiling Sass directly with PostCSS isn't possible. There's only a packages to use Sass-like syntax, or parse SCSS files, so that those can be transformed with PostCSS.

Like these packages: https://github.com/jonathantneal/precss https://github.com/postcss/postcss-scss

If PostCSS port would something which needs to be achieved, I'd start from scratch (ouch), well almost at least, and use maybe CSSNext and write close to spec CSS (custom css properties, color function, nesting, etc), combined with some import/mixin/function/linting plugins.

But even if PostCSS is my choice of tool, it really doesn't slow me down (much) if Blaze is using Sass. It's more important that the developer is comfortable with the tools and can be productive 😄

Just my 2c (woah, didn't mean to write so much..)

[gregorypratt]

Would this be a breaking change? The output would be the same wouldn't it? Would this be a v4.0.0 release or could it be done in v3?

[Kurre]

Imho, it could be both 😃

For those who are using /dist version it wouldn't be a breaking change since the output would be same as before. But for those who are using sources it would be a breaking change, since you couldn't use sources with your Sass workflow anymore. (Unless it's chosen to support Sass and PostCSS side-by-side).

Therefore, I'd say, v4.0 if only one source (PostCSS), v3.x if multiple sources (Sass and PostCSS).

[nmrgt]

To complete the @Kurre list, there is also a PostCSS plugin to have BEM naming shortcuts https://github.com/saladcss/saladcss-bem

[gregorypratt]

I've played around with PostCSS, and have some thoughts...

CSSNext is great, custom variables are awesome, as are color functions, custom-media are good, plus other things like font enhancements. Looking forward to them all being in CSS proper. However you can't use variables everywhere, inside custom-media rules for example. There are no built in loops, no arrays...yes I could find particular plugins that fill in the gaps but then how tested are these plugins? How much of learning curve is it for me and others to implement and maintain? What happens if the plugin ceases to exist??

I think porting over to PostCSS exclusively is probably not a wise decision. Sass is simply too powerful, flexible, well known and stable.

I propose to use Sass to compile into CSS, then use CSSNext to compile that into current CSS. I don't think it's useful to totally abandon Sass given the benefits it provides. I think I should use future features of CSS where possible without degrading the productivity of the development and maintainability of the code.

Thoughts?

[gregorypratt]

What do you think to something like this?

@import "mixins/settings.global";
@import "mixins/components.typography";

:root {
  --font-weight: $address-heading-font-weight;
}

.c-address {
  @include paragraph;
  font-style: $address-font-style;
}

.c-address__heading {
  display: block;
  font-weight: var(--font-weight);
}

This Sass is piped into CSSNext which produces the same output as the original Sass.

The benefit however is that as CSSNext features become real they can be turned off one by one in the gulp task config.

[gregorypratt]

Ok I've played around with PostCSS for quite some time now and personally I prefer my current build setup. I'm going to stick with that and work on supporting and maintaining features and improving accessibility.