Why I'm Excited About Native CSS Variables | Hacker News Reader

Why I'm Excited About Native CSS Variables

philipwalton.com

129 pointsclessg31 comments

> 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.

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.

How?

> 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?

By using percentage values?

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 :)

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.

I'm very excited for dynamic, succinct templating.

If you're looking for 'living' CSS with variables supplied by JS at the time the styles (or responsive queries) apply, there's a polyfill for IE8+ that includes this functionality that you can use everywhere today!

http://codepen.io/tomhodgins/pen/MKWOWW

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.

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

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.

> 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.

Funny you should mention that, I have such a polyfill to introduce Element Query syntax to all browsers IE8 and up, and one of the features we just added was the ability to use variables in your CSS supplied from JavaScript running on the page.

Demo: http://codepen.io/tomhodgins/pen/MKWOWW

Oh, and we also added a $parent selector to CSS, just for giggles :)

http://github.com/eqcss/eqcss < it's under MIT so feel free to use it and build on it

Polymer partially polyfills CSS Custom Properties: https://www.polymer-project.org/1.0/docs/devguide/styling.ht...

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?

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.

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.

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.)

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

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

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.

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.

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

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 and http://elementqueries.com

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

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

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

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

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, or support it, respond. This is shown in the article. I see no resistance to the feature being introduced in that, just disagreement on a part of the proposal.

> 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.

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.

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

Should be possible using `calc()`.

https://developer.mozilla.org/en/docs/Web/CSS/calc

Reply on news.ycombinator.com