Does this mean we can now also use expressions such as (pseudocode) "height: (x+1-y)px"?
Why I'm Excited About Native CSS Variables
11–20 of 33 posts
Re: Why I'm Excited About Native CSS Variables
#12Does this mean we can now also use expressions such as (pseudocode) "height: (x+1-y)px"?
Should be possible using `calc()`.
Re: Why I'm Excited About Native CSS Variables
#13> 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 ele…
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…
How?
Re: Why I'm Excited About Native CSS Variables
#14CSS should have just been a functional programming language to begin with.
Re: Why I'm Excited About Native CSS Variables
#15The 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.
Re: Why I'm Excited About Native CSS Variables
#16Being 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
Re: Why I'm Excited About Native CSS Variables
#17What 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.
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!
Re: Why I'm Excited About Native CSS Variables
#18> 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 ele…
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…
> 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?
Re: Why I'm Excited About Native CSS Variables
#19The 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…
> 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
Re: Why I'm Excited About Native CSS Variables
#20What 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 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.