
CSS Variables in Firefox Nightly - daw___
https://hacks.mozilla.org/2013/12/css-variables-in-firefox-nightly/
======
pornel
Please note that CSS Variables are not like SASS/LESS variables. They're
actually _custom properties_ that obey inheritance.

They're scoped to document rather than stylesheet, so you can override them in
parts of the document just like you can override any CSS property.

Example from the spec:

    
    
        :root { var-color: blue; }
        div { var-color: green; }
        #alert { var-color: red; }
        * { color: var(color); }
    
        <p>I inherited blue from the root element!</p>
        <div>I got green set directly on me!</div>
        <div id='alert'>
          While I got red set directly on me!
          <p>I’m red too, because of inheritance!</p>
        </div>

~~~
nfm
This sounds like a bit of an anti-feature to me. It might encourage a practice
that makes it very difficult to tell what styles will be applied to an element
without inspecting it in the DOM. I've been thinking about how to code for
maximum grepability recently and this is at odds with that.

~~~
X4
I also hoped for a macro style color function that just text-replaces all
occurrences of color: hackernews with #ff6600 when you define hackernews as
def: hackernews, #ff6600; That would allow total mumbo jumbo style CSS-Sheets
that look like Java or C++, if the authors would go that crazy..

However, I think that just copying how mixins and variables work in SCSS work
into the CSS4 spec would do wonders. _I 'm 100% for it_

------
transfire
W3C strikes again. They are uniquely gifted at creating ungainly and ugly
standards even in the face of widespread industry practices are already
commonly used (less, sass). I really want to know who thought `var-` prefix
was a banging idea.

~~~
city41
I suspect backwards compatibility has something to do with it. Old browsers
probably ignore var- attributes. But something like @var quite possible makes
IE5 or something throw fits.

~~~
Recoil42
Great, so in order to cater to the 1% of the population still using an archaic
non-standard browser, we screw over the spec for the rest of time.

Sound logic, isn't it?

~~~
simonw
Yes. If the syntax breaks older browsers, many developers will avoid using the
feature entirely.

~~~
arcatek
Many, but maybe (probably) not most.

~~~
airtonix
And any that do avoid using it now are always mostly lagards anyway.

------
bbx
CSS variables are the only reason I started using Sass and LESS in the first
place. But although these preprocessors come with other interesting features,
I never managed to truly incorporate them in my workflow.

The way I ended up solving the CSS variables issue (i.e. replacing the same
property/value combination in multiple locations) was to actually regroup
_selectors_.

For example, I'd have:

    
    
      #title,
      .nav a,
      .post-title em {
        color: #db4e44;
      }
    

The only annoying thing is that it can result in a long list of selectors
(although I'd put them on one line anyway). But one thing I truly appreciate
with this approach is that you can edit _any_ value with your browser's
inspector, and see it _instantly_ update all instances at once. It's great to
test out new colors for example.

The other option would be to have a specific class that would apply this
style. But then, you'd move the styling from the CSS to the HTML, and I've
always tried to prevent myself from breaking this golden rule.

~~~
crazygringo
But this still isn't a complete solution -- if you want the same color as a
"color" in one place, "background-color" in another, and "border-top-color" in
another, you're still repeating yourself. Likewise if you want to do math with
paddings/margins etc.

I don't know why, if you're using LESS or equivalent, you wouldn't use
variables. It makes for vastly more maintainable CSS than the approach you
take.

------
sergiotapia
Really ugly syntax.

    
    
        var-* ????
    

Who thought this would be a good idea?

~~~
byroot
Someone that did not wanted to generate syntax errors in older browsers ?

------
georgecalm
Does anyone know if there's a polyfill for CSS variables out there? Possibly a
library that creates plain old CSS out of the one that uses variables. It
would be useful until this is rolled out to other browsers.

~~~
andreypopp
There's rework-vars[1] for rework[2] which provides CSS style variables but
w/o inheritance so it's not a polyfill technically.

[1]: [https://github.com/visionmedia/rework-
vars](https://github.com/visionmedia/rework-vars) [2]:
[https://github.com/visionmedia/rework](https://github.com/visionmedia/rework)

------
chime
I like that you can overwrite the var(headersize) in a different style. That
makes these pretty powerful. However, var(headersize) is a lot to type,
compared to @headersize (like LESS) or $headersize (like SASS). CSS allows for
a lot of shorthand (#AABBCC = #AAA, table tr td a ~= table td a, * {}). Would
be nice if there was a shorthand for variables too since they'll be used so
much.

~~~
randall
I think they don't do this because of consistency with other declarations like
url() and the sort. CSS needs to be fast to process and easy to understand.

------
yashau
Note that you can also do this in Chrome/Chromium by turning on the "Enable
experimental Web platform features" flag.

------
dreamdu5t
This is disgusting. "var-" prefixes!? No. Just no.

Now there's another reason to use Rework, Stylus, LESS, or SASS.

~~~
yuchi
We're not talking about that kind of variables. CSS ones are a dynamic,
inherited, cascaded (is that a word?) set of vars.

------
oddshocks
FINALLY people fixing the tools instead of creating wrappers around them!
Thank you Mozilla!

~~~
byroot
Yep, it took only 5 years to be implemented by one browser, and will take
another 5 years to be usable in production.

It was really not worth it to create wrappers.

------
mekishizufu
The downside of this (unless I'm missing something) is that these variables
need to be evaluated on the client side and inevitably slow down CSS
processing (at least for the first time that is). I really like the fact that
you can preprocess both LESS and Sass (and others) to just plain CSS and hide
all of the dynamic behavior (far more then just variables).

~~~
Drakim
If the variables are constants, there shouldn't be any slowdown. The browser
could just inline replace the variable references with the actual values in
it's own internal representation.

~~~
jdmichal
They are not. The values can be redefined following the same CSS cascading
rules as everything else.

~~~
Drakim
But that's redefined as new constants again right? The internal representation
of the CSS inside the browser would just need to update the inlined values.

~~~
jdmichal
Yes, and by the time it's done doing that, you basically have a CSS processor
that does all the cascading rules. Or, you could just use the CSS processor
you will already be running on the same file. The whole point is that just
inlining a constant value with a preprocessor will not work, because the
values follow CSS rules.

~~~
Drakim
No, the point here is that there will be no slowdown, because the browser
doesn't need to reparse the entire CSS document every time it needs to refer
to that variable value, or anything like that.

It reads over the definitions ONCE (with all the CSS hierarchy and such), and
then establishes it's own internal constant value for that variable. Referring
to that value will be no more expensive than referring to a value that is set
by the CSS sheets like "FF55FF".

~~~
jdmichal
There is no singular value for a variable. (Otherwise they would be constants,
not variables.) Here's an example:

    
    
        :root, .green.applyColor {
            var-color: #00FF00;
        }
        .red.applyColor {
            var-color: #FF0000;
        }
        .blue.applyColor {
            var-color: #0000FF;
        }
        .applyColor {
            color: var(color);
        }
    

With this style sheet, items with the "applyColor" class will default to
green, unless they also have the class "blue" or "red", in which case the
color will switch appropriately.

So how, exactly, is a CSS processor supposed to read this definition once and
come up with a single internal constant for the variable "color" that can be
looked up in constant time? And how does that offer any advantage over just
using its already-programmed cascading rules to properly resolve "var-color"
whenever it encounters "var(color)"?

------
danabramov
By the way, [AbsurdJS][1] is an interesting alternative to Sass/LESS. It lets
you write your CSS in JavaScript (and have it compiled to CSS). Thus, you get
mixins, variables and plugins without some DSL to learn/use/depend on—all
written in JavaScript.

    
    
      [1]: http://krasimir.github.io/absurd/

~~~
ris
>all written in JavaScript

I do hope we're approaching the end of the era when this is used as a positive
statement.

~~~
erichurkman
We'll go full circle and go back to XML-in-JS, like Mozilla's now-defunct E4X
[1].

[1] [https://developer.mozilla.org/en-
US/docs/E4X/Processing_XML_...](https://developer.mozilla.org/en-
US/docs/E4X/Processing_XML_with_E4X)

------
xux
Wow CSS is becoming more and more like a programming language. Good job on
Firefox for pushing the boundary.

One thing though. The calculations don't seem very semantic. To calculate
something as simple as height/width, you need a long
calc(var(height)/var(width));

Maybe w3 can implement CSS variables with special characters like in PHP.

~~~
icebraining
Using $ to identify variables was proposed in the CSS working group. It was
ruled against in order to keep that syntax free for future developments (e.g.g
SASS-like macros).

[http://www.xanthir.com/blog/b4KT0](http://www.xanthir.com/blog/b4KT0)

------
simonrobb
I just can't see what the path to adoption of this looks like. How do you
achieve backward compatibility?

You put a box-shadow on your elements today and while it won't look quite as
shiny in browsers that don't support it, it's not going to affect usability.
If you put a variable in that stylesheet, say to make the background of all
your clickable elements blue, how do you provide a fallback for the browsers
that don't understand the directive? If my elements aren't blue in anything
except the latest build of FF, there's no way I can justify using the feature,
obviously (as much as I like the idea of it).

~~~
yuchi
Options: \- use only variables, and put `body { background: #eee; color: #333;
}` so this is the 'fallback' \- prepend a fallback style: `color: red; color:
var(main-color);` \- use a css preprocessor to mangle all the things --
somehow.

~~~
simonrobb
Prepending the fallback style was the option I was considering, but it does
really defeat the whole purpose of the idea. You'd end up with the same styles
that you would have without variables, plus all the duplicate rules using
variables, all for no gain.

If I were using a preprocessor, I'd just use the in-built variables of that
preprocessor I guess.

------
drawkbox
It would be great if there was a new standard like LESS/SASS for on the fly
browser CSS creation. Think of the download speed up and the simplicity,
removing minifiers, bandwidth, complexity. Also when new browser support
elements are added the intermediary layer will just be the global one always
even during development. Browsers will just add them to this instead of
prefixed properties moz- etc. Support can change with the same simple
stylesheets, browsers worry about it.

------
drinchev
I'm not sure why, but reading this news is not so exciting. SASS/LESS are
basically a standard ( along with Compass and other ), so I'm not sure how
CSSWG will get out of the mess they made with "-moz,-webkit,-o" and many, many
others ... Native support of CSS variables is like querySelectorAll. You got
it, but you still use jQuery, because of backward / forward support.

------
jccooper
Nifty. I'm really looking forward to using those in several years.

The need for CSS variables has only been apparent for about forever. What took
so long?

------
tiquorsj
Sass and less are really a kluge that just sheds light on how much CSS needs
this built in.

------
meerita
I don't like this.

I prefer the freedom of platforms like LESS or SASS. They can implement
changes faster and they can have full set of features without worrying about
updates or platforms. They just output standard CSS.

If we relay on browser features, we will be slower, we will tie up to vendor
differences and things will get complicate over time to develop something
cool, in fact, there will be projects for sure that re-unify what browsers
precompile, so, no to this.

I would suggest vendors to support the standard CSS spec to the max, and keep
this good work instead going something really new like this.

~~~
yuchi
As read on other comments: preprocessor variables have nothing to do with this
kind of variables. Read the spec, they're a very powerful tool.

------
joelthelion
What's next? CSS loops? Why not make CSS Turing-complete while they're at it
:)

~~~
robin_reala
CSS (in conjunction with HTML) is Turing-complete:
[http://stackoverflow.com/questions/2497146/is-css-turing-
com...](http://stackoverflow.com/questions/2497146/is-css-turing-complete)

------
kyriakos
would be nice if this eventually turned into something similar to sass or less

------
ozh
sooooo much better than SASS or LESS which require additional tools that break
workflow.

~~~
city41
Additional tools that break workflow have become a fact of web development
though. They don't even bother me anymore, I took that mental hit long ago.

A native CSS solution is definitely better in an ideal world. But we will
still need SASS/LESS/etc for years to come because in the real world old
browsers still get used a lot.

------
ape4
Is CSS Turing complete yet?

~~~
ygra
There was this: [https://github.com/elitheeli/stupid-
machines](https://github.com/elitheeli/stupid-machines)

