
Why I'm Excited About Native CSS Variables - clessg
http://philipwalton.com/articles/why-im-excited-about-native-css-variables/
======
yxhuvud
> In fact, I think it’s confusing to call them variables at all. They’re
> actually CSS properties, which gives them an entirely different set of
> capabilities and allows them to solve an entirely different set of problems.

I think this is the problem people have with them - they don't try to be a
good solution to the problem people actually have. A better designed solution
would have the most common case simple and elegant, and more esoteric use-
cases, like the ones they are trying to solve, may have esoteric solutions
like the proposed one.

~~~
chrismorgan
CSS Variables have been in Firefox for a year and a half now, and I’ve been
using them in my own projects for at least a year, while I’m producing the
thing in the first place—then when I have it as I like it, if it’s not purely
for me, I rewrite it for inferior browsers (though I believe I could use
something like PostCSS instead; I just haven’t).

They really are a _marvellous_ thing; my favourite example would be the
construction of truly responsive interfaces, tweaked for optimality at many
levels and continuous, rather than just things with three or four breakpoints;
with preprocessors, it’s tedious and painful; with CSS variables it’s _easy_
and _obvious_ —it pushes you in a direction that is _so much easier to make_.

In essence, they are solving a substantially different set of problems, but
one that is more useful and more general; the sorts of things people did with
preprocessor variables can normally be done in better ways with CSS Variables;
it helps guide you to a better position.

~~~
err4nt
> They really are a marvellous thing; my favourite example would be the
> construction of truly responsive interfaces, tweaked for optimality at many
> levels and continuous, rather than just things with three or four
> breakpoints; with preprocessors, it’s tedious and painful;

Anything with preprocessors is tedious and painful, yet I've been hand-writing
fluidly responsive layouts for years without predefined 'breakpoint' jumps in
the design. What is it about CSS variables that allowed you to change your
style?

~~~
jay_kyburz
By using percentage values?

~~~
err4nt
Are you asking me if I use percentage values to do fluidly responsive designs?
There's definitely some of that but most of the time it's even simpler than
that - just defining a max width or height on something and letting things
expand to fill their containers. Then you only have a few big containers in
the entire layout to worry about :)

------
RX14
What I am most excited about is manipulating these using javascript, which is
also something you cannot do with a CSS processor because the values are baked
into the CSS.

~~~
onion2k
I don't understand that use case. If you're happy using a JS value to update a
style, what's wrong with just updating the style in JS? If you're concerned
about performance then you can obviously do things like debouncing anything
that changes the style, or you could use a MediaQueryListListener to fire an
event your JS listens to when a user crosses over a media query breakpoint.

While it'll be fun to manipulate CSS properties using JS values, it doesn't
seem necessary.

~~~
philh
It seems like this would let you update lots of styles simultaneously, without
having to keep track of exactly which styles they are.

------
underwater
The author lists all the ways CSS variables are better than preprocessor
variables. But that is the same reason that the design is flawed.

JavaScript has shown us the value of designing new features in a way that they
can be polyfilled or emulated via a preprocessor, so that features can gain
adoption without developers having to wait for older browsers to die.

CSS variables were overdesigned in a way that makes this upgrade path
impossible.

~~~
philipwalton
Polymer partially polyfills CSS Custom Properties: [https://www.polymer-
project.org/1.0/docs/devguide/styling.ht...](https://www.polymer-
project.org/1.0/docs/devguide/styling.html#xscope-styling-details)

Also, for what it's worth, not all new JavaScript features are polyfill-able.
Proxies, for example, are impossible to polyfill, should they not have been
added? WeakMaps are also only partially polyfill-able, are they overdesigned
too?

~~~
underwater
I believe that where possible it makes sense to follow what is already
happening in the wider open source ecosystem, rather than trying to design a
solution from scratch.

There is a huge demand for constants/variables in CSS, as well as a widespread
use of preprocessors. The CSS variable spec does bring a lot of interesting
ideas to the table, but it does so at the expense of ignoring how people are
shipping code today.

Designing a solution that can be dropped into an existing pipeline can be
valuable even if doesn't introduce any new concepts or features. For example
Promises in JS are pretty simple and just replicate the functionality of
existing libraries, but they normalized existing patterns and made it possible
to trust that third party code would have consistent behavior. That was a huge
boost.

------
monk_e_boy
These look neat. I wonder what they will be like to debug. I spend a lot of my
job fixing problems that the designers have left in the CSS, like "Why on this
page is the button margin 2em, but on all the other pages it's 1.5em." I guess
with variables thrown into the mix, it'll make this debugging harder.

~~~
chrismorgan
Why harder? Surely if people actually use them, you’ll at least have labels
attached to things—semantic labels, hopefully, rather than simple and opaque
values?

(I wish people would use `calc()` too where appropriate.)

~~~
monk_e_boy
I wonder what the css insight would show? Both the computed value and variable
name?

------
Ono-Sendai
CSS should have just been a functional programming language to begin with.

------
PebblesHD
I quite like the example of styling buttons in the header using a more
component-like architecture, this could lead to some interesting developments.
I look forward to seeing this progress.

------
khgvljhkb
Being able to manipulate these from JS would be great. Then compile-to-js
languages (Clojurescript & Elm) can use their (better) programming model for
styles as well.

~~~
err4nt
If you're looking for a way to use JavaScript variables directly in CSS styles
there is an Element Query polyfill that includes that feature:
[http://codepen.io/tomhodgins/pen/MKWOWW](http://codepen.io/tomhodgins/pen/MKWOWW)

You can reference one line of JS in your CSS style, and the returned value is
what is output in your CSS at the time the (responsive) style applies. This
value can be a Js variable set elsewhere on the page, the output of a
function, or a string or single line of JavaScript that is evaluated in-place.

The var() feature is new and only in the v1.0.0 branch right now, but to read
about the other features of this plugin check out
[https://github.com/eqcss/eqcss](https://github.com/eqcss/eqcss) and
[http://elementqueries.com](http://elementqueries.com)

------
PaulHoule
It is amazing that there has been so much resistance to this sort of thing.

~~~
philipwalton
Indeed! That's why I wrote the article :)

~~~
talmand
Debating the syntax is not the same as resisting the feature.

~~~
philipwalton
I don't see a lot of "debating" going on. If you want to point me to some
constructive debates, that would be nice.

~~~
philipwalton
> I guess that depends on how you define debate. I'm referring to that the
> proposal is made and some people show their distaste for part of what is
> proposed. Those that made the proposal respond. I see no resistance to the
> feature being introduced in that, just disagreement on a part of the
> proposal.

Just to be clear, neither I nor Addy Osmani proposed CSS Custom Properties.
We're just excited about the feature and sharing it with others. So when
people respond negatively to us, it doesn't feel like debating.

The time for debating was when it was being discussed in the working group;
before it was implemented in three different browsers.

~~~
talmand
I realized the difference, which is why I edited and added in those that
support the proposal. Weird that your response is listed underneath the post
you are quoting.

So, you should be immune to a negative response when you publicly state your
support for a feature? People don't like how the feature is implemented and
say as much. Like I said, it depends on how you define debate and I guess it
doesn't match your definition. That's fine with me. But that doesn't mean I
don't get to refer to it as a debate. I see it as a debate and if you
disagree, that's fine with me as well.

People did debate during the proposal and as such things usually go, people
will continue to do so. People had similar issues with flex and gradients.
Note that the syntax for those were altered after they were implemented into
browsers.

------
amelius
Does this mean we can now also use expressions such as (pseudocode) "height:
(x+1-y)px"?

~~~
zenojevski
Should be possible using `calc()`.

[https://developer.mozilla.org/en/docs/Web/CSS/calc](https://developer.mozilla.org/en/docs/Web/CSS/calc)

