Preprocess future-proof CSS features

[giuseppeg]

Would you be open to add a few future-proof PostCSS plugins to transpile things like custom properties, calc, custom media queries?

This could be as simple as using the postcss-cssnext plugin or set up a lil preprocessor like we did for suitcss.

If there is interest I can probably help out.

[mxstbr]

There's an ongoing discussion about this in #78!

The TL;DR by @gaearon about cssnext is:

Whatever we add, it needs to be rock-stable. I’m worried about issue lists like this: https://github.com/postcss/postcss-import/issues.

[giuseppeg]

That one is a more broad topic since it is about adding support for SASS/Less.
What I was asking here is if there is any interest in transpiling future-proof features like we already do in JavaScript with Babel.

Regarding cssnext, yep I agree that "there’s a lot of stuff there" – if we want to play it safe we could just add imports, variables (custom properties), calc, custom-media and autoprefixer.

Anyway I am fine with waiting and see where #78 goes.

[gaearon]

We are open to add transpilation for standardized features if those tools don't have large issue lists. We don't want to recommend broken tools by default.

[gaearon]

Since #78 has gone a little bit too broad, let’s use this issue for specific proposals about PostCSS plugins that are safe to enable, work great, correspond to stable specs, and give at least some of the features people want.

[giuseppeg]

Stable

• postcss-custom-media

TBD

N.B. the plugins below don't support dynamic custom properties i.e. cp are compiled to static values.

• postcss-custom-properties for simple constants (from this blog post it seems that Facebook uses them too)
• postcss-calc
• postcss-apply
• postcss-color-function
• postcss-easy-import would be great but there are some buggy edge cases – fwiw I never had issues with it. Considering that webpack creates a bundle though probably it is not needed (we can run postcss on the bundle)

Personally I also use postcss-autoreset and Stylelint but those require custom configuration.

[MoOx]

My 2 cents:

• postcss-import "just" need a maintainer + revert to v7 (which was more stable than the current one).
• I can handle a revert to postcss-import to v7 if that can be useful to a lot of people, should take a second.
• postcss-easy-import use postcss-import v8, so forget this one imo.
• postcss-cssnext does not includes postcss-import !
• postcss ecosystem is not rock solid anyway (postcss-import is a proof, imo a core plugin, does not get any love from anybody - and I asked for help multiples times)
• I can give access to some maintainers for a lot of postcss plugins I created (mostly all future proof syntax related plugins).

I am myself using CSS-in-JS (via RN-web) and avoid CSS when possible.

[glennreyes]

I'd love to see postcss-cssnext as it has autoprefixer and pretty rock solid and optional features baked in

[davidkpiano]

I would strongly advise to take caution with CSS custom properties, and if something like postcss-custom-properties were to be included, it would be a good idea to set: preserve: true (not computed) in order to maintain the spec behavior as closely as possible.

Here's a trivial example of a potential issue:

:root {
  --foo: green;
}

header {
  --foo: red;
}

h1 {
  color: var(--foo);
}

What color is <h1>? Answer: it depends. It's 🍏 by default, but when it's in a <header>, it is 🔴, because custom properties cascade and inherit. Here's another fantastic example of that behavior: http://lea.verou.me/2016/09/autoprefixing-with-css-variables

Keep in mind: all major browsers (except IE and Edge, where it is in progress) support CSS Custom Properties.

[ai]

I like this feature: https://github.com/postcss/postcss-media-minmax

@media screen and (width >= 500px) and (width <= 1200px) {
  .bar {
    display: block;
  }
}

Polyfill is very stable. Spec is a official draft: https://drafts.csswg.org/mediaqueries/#mq-range-context

Feature is pretty useful, because it is always hard to work with min-/max- stuff instead of >=/<=.

[ai]

will-change polyfill is very useful, but it is not so stable (will not work if you defined backface-visibility on same tag, but with different class). So it is open question, should we add it.

https://github.com/postcss/postcss-will-change

[ai]

I think this plugin is mush-have: https://github.com/postcss/postcss-color-function

1. It is very useful, color transformations are one of the most popular feature
2. Spec is very stable
3. Polyfill works without any problem (any lack of documentation)

[ai]

:any-link is useful, stable and have no problems in polyfill: https://github.com/jonathantneal/postcss-pseudo-class-any-link

[ai]

:matches is useful, stable and works well: https://github.com/postcss/postcss-selector-matches

[ai]

All CSS4 colors polyfills:

• https://github.com/postcss/postcss-color-gray
• https://github.com/postcss/postcss-color-hex-alpha
• https://github.com/postcss/postcss-color-hwb
• https://github.com/postcss/postcss-color-rebeccapurple

[jquense]

Like me and @taion noted in #78, there are few that aren't/can't be to spec, or actively allow non-spec behavior. In particular the color() function is insiduously wrong, in that it doesn't distinguish between lightness(+10%) and lightness(+ 10%) (did you even notice the difference?) in the modifier functions. That whitespace should determine whether the change is absolute or relative, but it doesn't distinguish right now

[taion]

As @davidkpiano and @jquense note above, most of the more useful cssnext features have significant caveats.

• Custom properties only polyfill the simple case where the property serves as a variable (with clunky syntax), and doesn't handle the new cases that the syntax actually allows
• Color function does non-spec-compliant things around whitespace between modifier sign and modifier value
• calc() polyfill only works if all units match
• Nesting improperly allows Sass-like concatenative selectors: Concatenative selectors csstools/postcss-nesting#17

cssnext is very cool, but it's not like Babel in that the features it transpiles are transpiled in a manner that is close enough to spec compliant to "just work".

Some of the smaller polyfills in there might be nice, but the "big" ones have meaningful caveats attached.

[taion]

The capsule summary is that, for people not paying close attention to the actual spec, Babel loose mode is order of magnitudes safer than the majority of new features enabled by cssnext, and CRA isn't even using that: #198

[deathmood]

the only thing that I really would like to see are css variables. They are already available in chrome and firefox -- so it's like a working and already implemented thing. But it does not work in IE and Edge that is why we need to post process it.

so my vote goes for https://github.com/MadLittleMods/postcss-css-variables

[taion]

They're not variables, they're custom properties – and as the repo you mentioned notes, they can't be correctly polyfilled, so you end up with support for either an odd arbitrary subset, or non-spec-compliant behavior that you're actually likely to run into (unlike with Babel).

It's not at all a reasonable default.

[ai]

@jquense could you please open a issue in postcss-color-function. Your example with space could be fixed and it is not fundamental problem of polyfill. What else color() issues do you have?

[ai]

@MoOx

Not a single PostCSS plugin is rock solid

Relying on PostCSS is a very bad idea on many levels

each postcss plugins I know have tons of issues. All of them.

Using PostCSS for stuff like PreCSS is kind of stupid

I agree with you, that CSS specs are not so stable to have future-proof plugins (Custom Media removing change my mind), but don’t be so toxic about speaking of all PostCSS.

Autoprefixer is rock solid and no big knowing issue and using it is a great idea on any level ;).

CSS Modules works great too and definitely don’t have “tons of issues”

PostCSS is not only “cssnext” stuff. There are many other tools, which works great. And create-react-app already use some of this tools (Autoprefixer and css-loader).

Other great tool that could be implemented in zero-config app is a Stylelint — it has non-codestyle rules to avoid mistakes.

[MoOx]

@ai My goal is not to be toxic, it's to be relevant to CRA requirements.
Sure Autoprefixer is rock solid (I had this one in mind when I said that some are probably fine). I didn't take this one into account since it's already built-in.
CSS-Modules is also very nice, but it's a "special" plugin, probably too opinionated, and you know it.
Stylelint is also not a classic PostCSS plugins too. I guess this one can be a good choice. But here we have a linter, not a preprocessor.

Obviously there is some good in PostCSS :)

Except Styelint with a small config (even the styelint-config-standard include stylistic rules) and Autoprefixer, I don't think something will be the right fit for CRA.

[giuseppeg]

Should we use github's reactions to decide what to do about this issue?

I would suggest to use ±1 (thumb up/down) on this comment to decide if we want to:

1. 👎 keep the status-quo and close this issue
2. 👍 keep the status-quo but add the possibility to customize postcss via config file as described in my previous comment

cc @gaearon

[MoOx]

No config, means no config. I am pretty sure nobody want to add config just to support the (not really mature) PostCSS ecosystem :/

[giuseppeg]

@MoOx I don't have strong opinions, I just think that we shouldn't discuss if PostCSS is good|bad|stable|unstable forever :)

fwiw 2) would be an add-on only feature i.e. if you want to configure postcss you have a way to do so otherwise continue to do what you were doing :)

fwiw² I also think that in the long run css-in-js will win so shurg

[ai]

I agree that “no config” means no config”.

(not really mature) PostCSS ecosystem :/

@MoOx don’t be toxic. If cssnext plugins is not really mature, doesn’t mean that other plugins are not really mature. Stylelint, Autoprefixer, PostCSS Assets and CSS Modules show a great example of mature ecosystem.

It is especially painful to hear “not really mature” from your, because you a maintainer of cssnext, and esosystem problems in cssnext is on you. Don’t spread cssnext’s lack of maintaibility to other well maintained plugins.

[yordis]

Let's find a solution that works for everybody

No config means no config

Well, then don't force the package to lookup something and have predefined PostCSS plugins that only are well maintained and curated.

Config, Hurrah!

Just add a parameter that is a Javascript file, arguments could be many things open to people who know more than me, where you could whatever Javascript allow you to do 😄
This way pretty much we cover the use case of advance users like me, who don't want to lose the flexibility of adding some stuff.

@giuseppeg I support both cases, 0 config and advance user, because I really dont want to lose the flexibility of adding some good stuff like @ai called, so

[ai]

Anyway I think that we could close this issue. Main topic was about future-proof plugins. As was shown CSS specs are not so stable as ES2016 was in 2015, so plugins (even very well done with good support) could not be future-proof for zero-config case of CRA.

@yordis maybe you should open a separated issue about config.

[yordis]

I would prefer @gaearon to open a new issue if need it. The core contributors have the final word on this.

[daviestar]

For design-led websites - which is a lot of websites, and what I make all day - unfortunately I can't use this amazing, maintained, JS build tool if it doesn't support SASS, or any kind of CSS betterer.

😔

If I could hook my own CSS (and other asset) build tools in with this somehow, and have the browser update with changes, I'd find a way to make it work.

[gaearon]

For design-led websites - which is a lot of websites, and what I make all day - unfortunately I can't use this amazing, maintained, JS build tool if it doesn't support SASS, or any kind of CSS betterer.

If I could hook my own CSS (and other asset) build tools in with this somehow, and have the browser update with changes, I'd find a way to make it work.

It supports SASS in the exactly same way people have been using SASS for years. Run a console SASS watcher, and import the resulting CSS from your JS files.

[daviestar]

Thank you, I ended up using gulp to build all my non-js tasks.

For SASS, I compile to _styles.css at the project src root, import that css file at my JS root.. and update npm start to

npm-run-all <gulp task> <react scripts>

and everything works great.

[giuseppeg]

@gaearon I feel like that we can close this issue unless you want to implement this thing

[tonyxiao]

@daviestar do you have one css file per component then? Or just a single massive _index.css file at project root?

[daviestar]

@tonyxiao I put SASS files in with my components, but as I said above I don't really agree I should import them into JS as IMO, CSS doesn't work that way. I can easily avoid it by compiling all my SASS files to one CSS file at the root using gulp, then just import that so webpack picks it up in development.

[tonyxiao]

Got it, thanks a pretty workable approach if you just completely avoid importing css into js. thanks for sharing @daviestar

[gaearon]

Let’s close as there is no consensus and I don’t feel comfortable proceeding with this.

[jonathantneal]

That Sassy nesting has finally been fixed.

[MoOx]

FYI, I deprecated cssnext in favor of postcss-preset-env, you might want to think about this one that offers stages like babel-preset-env!

[ai]

Yeap. With postcss-preset-env we can enable only stable CSS specs. It has stage option same as in Babel.

[gaearon]

We run postcss-preset-env now.

[jonathantneal]

I’d love to share this with my family and friends. I wrote PostCSS Preset Env, the tool you are using to future proof CSS. I hope it’s not presumptuous to ask, but might it earn a mention or thanks in the blog notes, @gaearon?

https://reactjs.org/blog/2018/10/01/create-react-app-v2.html

[gaearon]

We should probably include it into the notes. I forgot.