Foundation-sites: PostCSS with Sass Integration?

[corysimmons]

Carrying on the conversation from https://github.com/zurb/foundation-sites/issues/9875#issuecomment-296194753

Proposal for Foundation to migrate to PostCSS.

Thread theme music is https://www.youtube.com/watch?v=sh6V1zMmbuU

[IamManchanda]

Nice Music!

[corysimmons]

Pros:

• All the power of JS instead of a subset of misc functions (for instance, Sass will never have pow—which is really handy for working with ratios).
• Works with every CSS preprocessor AND vanilla CSS, so we're no longer ostracizing Stylus/LESS users.
• Super fast.

Cons

• Docs aren't perfect. We could help with that though.
• It's a huge undertaking.
• The syntactic sugar libs (e.g. nesting, variables, etc.) for it are buggy—especially when you start to combine them, especially when layering a real preprocessor in.

I've found PostCSS is perfect for making libs. Preprocessors are perfect for syntactic sugar.

Foundation is a lib.

[kball]

Another interesting thing I was thinking about postcss for was related to Container Queries. We did some experiments with container queries using https://github.com/ausi/cq-prolyfill that are REALLY COOL! However the prolyfill doesn't work well with scss which would make it hard to integrate container queries into the framework itself... UNLESS we move to postcss and set up our own handling of it... which would then enable us to really adopt container queries at a structural level if we wanted to. :D

[corysimmons]

I don't see how PostCSS (compiles to valid CSS) has anything to do with a polyfill (requires JS at runtime).

I think element queries are amazing and https://github.com/eqcss/eqcss has been trying to get the W3C to pay attention to his spec for it for a while...

I'm all about progressive enhancement but almost everything on clearnet relies on JS, so wouldn't be opposed to it.

Anyway, again, it's not related to PostCSS so should probably be a new issue.

[kball]

The JS polyfill is the runtime; the way to specify the container/element queries use some extensions on CSS that caused SCSS preprocessors to barf when I was playing with them, which makes it hard to use in a systematic way within the framework. Was thinking that PostCSS might give us a way to work around that.

[corysimmons]

Ah, weird. I'm not sure I'd break SCSS for people so I could use element queries though. Personally, I use Sass for sugar and some polyfill acting weird would upset me. That said, I'm sure we could dev a PostCSS prolyfill that would work well with Sass.

[tomByrer]

I like PostCSS; they have modules to process some things SCSS, people use it anyway for Autoprefixer, & other PostCSS modules are handy.

[paxperscientiam]

Just for reference, node-sass can be combined with post-css nicely.

EG:
````javascript
function buildCSS() {
sass.render(sassConfig, function(err,result) {
//
if(!err){
postcss([
// (1) unprefix the css
unprefixer,
// (2) adds missing NON-prefixed attributes and values
flexboxfixer,
// see coverage above
cssfixer,
// (3) compress your CSS mucho, which includes autoprefixer
prefixer(browserslist),
cssnano(post.cssnano)
//
//
])
.process(result.css.toString())
.then(function (result) {

        fs.writeFileSync(style.out,result.css);
    });
} else {
    term.red.error(err.message+ 'on line '+ err.line+ '\n');
}
});

}
````

[corysimmons]

If you guys do PostCSS, I can port my ratio method from postcss-ant to Foundation, allowing for these types of layouts: https://alistapart.com/article/content-out-layout

Then people could do something like: https://codepen.io/corysimmons/pen/wdJKrq?editors=1100

Designers want to use ratios, but keep having to work with simple fractions. It'd be something unique to your grid.

[tomByrer]

Looks great @corysimmons; I'd love me some Golden Ratio!

But I'd imagine backwards compatibility + more complex core codebase would be an issue; could a ratio plugin be better?

[corysimmons]

Oops, I added what it might look like in Sass while simultaneously promoting PostCSS. Fail.

tbh, I'm not sure how to approach it in Sass off the top of my head. It can _probably_ be done. I suppose some crazy loop stuff would work, but taking gutters into account and such, bleh... it just always seems Sisyphusy.

It just bothers me to think of weird loop hacks to workaround Sass' shortcomings... Why? Because it's popular. So is PostCSS, and it has all the power of JS.

---

A completely separate reason for PostCSS would be that there are more devs moving to CSS-in-JS than there are devs hanging out around the Sass ecosystem.

If you write the JS in PostCSS, people can use it in whatever frontend they want like. They can also just import what they need instead of the whole framework.

import React, {Component} from 'react'
import {Typography, Grid, Cell} from '@zurb/foundation/sites/react'

export default class App extends Component {
  render() {
    const mobile = '500px';
    const desktop = '800px';

    return (
      <Typography>
        <Grid mobile="1/3 2/3" desktop="1/4 1/2 1/4">
          <Cell>1</Cell>
          <Cell>2</Cell>
          <Cell>3</Cell>
        </Grid>
      </Typography>
    )
  }
}

You can reuse a lot of the same JS to generate custom dist stylesheets.

So far as people who don't use CSS-in-JS, we could _still_ rely on the same parts of a single codebase, just a different API (that would be consistent throughout every preprocessor and vanilla CSS):

// style.scss, or style.styl, or style.less, or style.css
@zf-breakpoints mobile: 500px, desktop: 800px;

.grid {
  zf-grid: mobile(1/3 2/3) desktop(1/4 1/2 1/4);
}

---

Yes, it'd be challenging.

Yes, it's possible and I think it's the best solution as opposed to sticking with weaker tech for popularity that _will_ fade as more-and-more frontend devs get CTO positions and make CSS-in-JS mandatory.

tbh, I'm not sure when you're planning to release your next version so it might not make sense to table-flip if it's just around the corner, but I think these arguments are valid for the future, or other framework authors.

[kball]

tag @brettsmason if you haven't seen this I'd love your thoughts in here.

With regards to versions, I don't think this makes sense for 6.4 (intended to come out mid to late next month) but we can definitely explore for 6.5

[corysimmons]

Any ETA on 6.5? Might not make sense to change the grid's API just to have a new one in a couple months.

The PostCSS stuff would be cool (especially if it were built with React/Vue in mind), but it's ambitious and I'm sure would make a lot of Sass devotees angry at first.

Not sure I have anymore arguments for it, so just ping me if you want to go through with it and I can help get someone up-and-running with PostCSS dev.

[brettsmason]

I'm completely open to the idea of moving to PostCSS. Having said that, I know very little about it to be honest and dont know what would be involved at all. Cory knows his stuff so I trust what he says and it does sound good. I would of thought 7.0 would be a better option though, as I get the sense it might take a bit of work and be quite an adjustment...

I think you need opinions from more experienced people than me on this though 😄

[IamManchanda]

I would of thought 7.0 would be a better option though

:+1:

[tomByrer]

Yes, drastically changing build tooling sounds more like a Major Version change, unless PostCSS will run parallel to Sass? I think PostCSS can do most Sass processing, but folks may have other Sass dependencies that may not be compatible.

[corysimmons]

Yeah it'd be a huge breaking change across the board.

[alanonthegit]

@kball How does cq-prolyfill conflict with scss? I've been using it with Foundation 6 for over a year. It has support for preprocessor syntax - https://github.com/ausi/cq-prolyfill/blob/master/docs/usage.md

[kball]

@ar-stackrox Good catch! I may have missed that when I was playing around with it... awesome.

[alanonthegit]

@kball No problem! I also have a really advanced responsive typography solution using container queries. I plan to write a medium blog about it, but if you're interested in studying it for inclusion with Foundation, I can also share it with you guys at some point.

[corysimmons]

Can we migrate the element query stuff to another issue since it's not PostCSS related (or is it?)?

[IamManchanda]

@corysimmons Yes we sure can!

[IamManchanda]

Looking to learn postcss a bit these days and must say it's not that difficult to switch from
=> Sass/CSS to Sass/PostCSS

https://www.postcss.parts => Sass
https://github.com/postcss/postcss-scss

[fawmi]

I haven't worked with Postcss at all, but I believe it should only replace sass if it provides a practical advantage over sass, and not because it is the new cool kid in the city.
Currently busy updating a project to 6.4 , i can say that not matter how easy the upgrade path is and how less the breaking changes are, something takes hours of your time.
Newer versions should bring more features (if necessary) , fix things and not break them.

I suggest postpondig this to foundation 8, as we have seen lots of breaking changes in recent versions of foundation.

[IamManchanda]

PostCSS won't replace Sass ...
Currently we are Sass/CSS
Then, it will be Sass/PostCSS of some sort!

[IamManchanda]

https://webdesign.tutsplus.com/tutorials/using-postcss-together-with-sass-stylus-or-less--cms-24591

[JeremyEnglert]

Lets discuss this for V7. Too many breaking changes for V6.

[IamManchanda]

It seems like that this is already labelled for v7 and we closed it by mistake so we are reopening it... Thanks!

[JeremyEnglert]

V7 requests are being closed for the time being. We have them labeled so we can readdress them in the future.