CSS Variables

[samginn]

Hi, I have found create-react-app to be a wonderful asset to rapidly setting up and maintaining react apps. I found myself, however, forking create-react-app in order to inject postcss-cssnext to add css variables. I know this has been discussed before ( #130 ) and rejected since cssnext was considered too unstable to be supported by CRA.

I feel, however, that css variables are something that most developers would find useful (and nearly essential when designing complex apps). I would rather avoid having to resort to a beefy solution like SASS or Less when future-proof css will work just fine. I am also not a fan of CSS-in-JS solutions. Further, I know that Facebook itself also uses CSS variables in some of their React apps.

Would you be open to reconsidering CRA support for css variables?

[gaearon]

I don't know enough about CSS variables but from discussion in #130 it seemed like they're not really "future proof" because they work differently than they would in browser. This seems like a no-go but maybe I misunderstand. Can you elaborate?

[benknight]

#130 is a massive discussion, so TLDR, from the postcss-custom-properties repo:

The transformation is not complete and cannot be (dynamic cascading variables based on custom properties relies on the DOM tree). It currently just aims to provide a future-proof way of using a limited subset (to :root selector) of the features provided by native CSS custom properties. Since we do not know the DOM in the context of this plugin, we cannot produce safe output.

But assuming all you want to do is define some custom props on :root and use them in your styles, the nice thing about CSS Custom Properties is that your development browser probably already supports them, so they will "just work" while you're developing, and then you can just npm install --save-dev postcss-cli postcss-custom-properties and add a postbuild script to package.json like follows:

// ...
"scripts": {
  // ...
  "postbuild": "postcss --use postcss-custom-properties --replace build/**/*.css"
}

[tobyl]

I've been following the discussion on CSS in CRA. I have previously used Sass, CSS Modules and styled-components.

I greatly admire the pragmatic approach favoured by CRA, and I'm looking forward to seeing the result of a closer look at how CSS should be handled (as mentioned).

For the record, variables accessible in both CSS and JS would be amazing (CSS Modules offers this, I think).

[wcandillon]

I would like to use CSS variables in my CRA project and have them polyfilled post processing since this feature is not support by many browsers.

[wcandillon]

Thanks for the tip @benknight!

[gaearon]

I'm still confused about how https://github.com/postcss/postcss-custom-properties works.

It says it only can handle a subset of the spec. So what happens if you use something more dynamic than it supports? Does it emit invalid output? Silently keep the syntax without transforming it? Warn? Error?

[benknight]

@gaearon I made up a little demo to check how it handles dynamic cascading variables, and here's an example before & after:

Before

:root {
  --first-color: #488cff;
  --second-color: #ffff8c;
}

#firstParagraph {
  background-color: var(--first-color);
  color: var(--second-color);
}

#secondParagraph {
  background-color: var(--second-color);
  color: var(--first-color);
}

#container {
  --first-color: #48ff32;
}

#thirdParagraph {
  background-color: var(--first-color);
  color: var(--second-color);
}

After

#firstParagraph {
  background-color: #488cff;
  color: #ffff8c;
}

#secondParagraph {
  background-color: #ffff8c;
  color: #488cff;
}

#container {
  --first-color: #48ff32;
}

#thirdParagraph {
  background-color: #488cff;
  color: #ffff8c;
}

So you can see it just left the --first-color override on #container alone, which makes sense because this is future friendly.

[gaearon]

What about this concern? #130 (comment)

[benknight]

@gaearon right so again the giant caveat with postcss-custom-properties is that dynamic cascading is not supported, so its primary use case is for setting static, global variables on :root, and as I imagine this satisfies what most people here are looking for. It's just a find/replace on custom props set on :root.

In the unfortunate case that an author uses cascading dynamic variables anyway, despite this caveat, the results would appear as expected in browsers that support CSS custom props, and likely broken in browsers that do not.

In the comment you linked, it appears he's advising setting the preserve flag to true, arguing that it's more future compatible. I buy this argument, but the results are basically the same as both outputs would yield the same visual result in old and new browsers:

Input

:root {
  --foo: green;
}

header {
  --foo: red;
}

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

Output

with preserve: false

header {
  --foo: red;
}

h1 {
  color: green;
}

with preserve: true:

:root {
  --foo: green;
}

header {
  --foo: red;
}

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

Anyway, just providing info here to help you better decide whether it's worth adding to the postcss configuration or not. In my opinion, it's trivially easy to add it as described in my comment further above.

[alexarena]

From what I’ve gathered from the MDN compatibility table, CSS variables have been in modern browsers since as early as 2015 and as recently as mid-2017.

• Firefox 42: 3rd Nov, 2015
• Opera 36: ~February 2016
• Chrome 49: 2nd March, 2016
• Safari 9.1: 21st March, 2016
• Edge/EdgeHTML 15 : ~April 2017

When this issue was opened in 2016, it was pretty fair to assume that a large portion of an app’s user base would be on an unsupported browser.

Given that we’re a year+ out from major browsers adding CSS variables, is it a good idea to backfill support for this feature given there exists at least one (dynamic cascading) pretty large inconsistency with the actual spec?

I feel this could introduce unexpected behavior in users’ apps, especially versus if they added postcss-custom-properties themselves, after identifying a need for its inclusion and understanding its inherent tradeoffs.

[gaearon]

Yeah I suppose by now it’s not as necessary. We’ll also include optional Sass and CSS modules support in the next release for people who feel they need them. So I think this is sufficient.

[TryingToImprove]

IE11 will not work. I think that this issue should somehow still be resolved. I am trying to fix some issues I have with IE11, where this is related. To test it I will have to build and use the postcss solution to see if my issue have been resolved.

It would be awesome if it was possible to use CSS-variables as #1283 (comment) describes