CSS Variables in Firefox Nightly

https://hacks.mozilla.org/2013/12/css-variables-in-firefox-nightly/

by daw___ • 13 years ago

186 67 13 years ago

hacks.mozilla.org

kyriakos• 13 years ago

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

bbx• 13 years ago

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.

samwillis• 13 years ago

The long list of selectors can ba a problem too, IE 6-9 only supports up to 4095 selectors per style sheet (http://blogs.msdn.com/b/ieinternals/archive/2011/05/14/10164...). However there are workarounds like @importing multiple style sheets.

nawitus• 13 years ago

I've found that nested rules are useful on almost every stylesheet. That, and variables, are the two main LESS features I use.

mmahemoff• 13 years ago

Arguably a more maintainable technique would be to use multiple classes and define, e.g. a "brand" class just for this color, so you can have a simpler standalone rule:

    .brand {
      color: #bada55;
    }

See OOCSS for more details.

While that's good practice, it's a challenge to get it right on a large legacy systems, so I still find variables useful in practice. Also, it's nice to be able to perform functions involving variables, e.g.

    .brand {
      color: lighten($link-color, 20%);
      background: ($link-bg + $page-bg)/2;
    }

prezjordan• 13 years ago

Sometimes you want the color to match the border color. The properties are not always the same, which is what causes repeat.

Variables are also useful when you can do calculations on them.

crazygringo• 13 years ago

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.

city413• 13 years ago

I have found with JS heavy frontends, simple solutions like this stop being effective quickly. I have about as many sass file as I do JS files in my project. Being able to use variables defined elsewhere in all those files is essential.

cheapsteak• 13 years ago

SASS can give you the same result:

    %red 
      color: #f00
    %blue
      color: #00f
    header
      @extend %red
    div
      @extend %blue
    #foo
      @extend %red
    p
      @extend %red

gets processed into

    header, #foo, p {
        color: #F00;
    }
    div {
        color: #00F;
    }

codepen sample: http://cdpn.io/JoHAv

chime• 13 years ago

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• 13 years ago

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.

georgecalm• 13 years ago

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.

camus2• 13 years ago

Is this the final variable spec?, creating a simple processor should not be too complicated,the issue would be on the javascript side,since it seems these vars are accessible from javascript.

andreypopp• 13 years ago

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 [2]: https://github.com/visionmedia/rework

yuchi4• 13 years ago

You cannot build a polyfill with full feature-parity with the sole CSS. How do you manage the following one:

    a:link { color: var(main-color); }
    .important-quote { var-main-color: red; }

    /* <div class="important-quote"> <a href="#">Hi, I should be red;</a> </div> */

Mh.. Well you could actually do some kind of @extend-on-steroids, if you do not care to bloat your styles.

danabramov• 13 years ago

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/

ris2• 13 years ago

all written in JavaScript

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

erichurkman• 13 years ago

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

ozh• 13 years ago

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

ahoge• 13 years ago

They have a watch mode and there are also source maps or debug mode. It's basically as if browsers would support it natively. The workflow is fine, really.

city413• 13 years ago

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.

nness• 13 years ago

If your coding your CSS by hand, without tools like SASS\LESS, I would say you don't actually have much of a workflow.

ape4• 13 years ago

Is CSS Turing complete yet?

ygra• 13 years ago

There was this: https://github.com/elitheeli/stupid-machines

jccooper• 13 years ago

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?

mekishizufu• 13 years ago

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

Drakim3• 13 years ago

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.

jdmichal3• 13 years ago

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

oddshocks• 13 years ago

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

byroot2• 13 years ago

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.

xux• 13 years ago

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• 13 years ago

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

transfire• 13 years ago

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.

4thjuly• 13 years ago

I wasn't involved so don't know first hand but suspect the gory details were discussed by everyone in the working group. http://lists.w3.org/Archives/Public/www-style/. Or were you being sarcastic? ;)

city413• 13 years ago

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• 13 years ago

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?

ris2• 13 years ago

Please realize that this proposal does much more than less/sass variables before you pooh-pooh it. e.g. it has to potential to work dynamically.

jonathanhefner• 13 years ago

Which makes it more difficult (impossible?) to polyfill. For the time being, I see that as an anti-feature.

qznc• 13 years ago

As far as I know, no major browser even tries to support text/sass or text/sass for stylesheets.

pornel• 13 years ago

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• 13 years ago

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• 13 years ago

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

ssafejava• 13 years ago

This is a fantastic feature, and something that preprocessors like SASS/LESS cannot do without complicated workarounds.

There are often times in my CSS workflow where I want to do something similar to this:

  .widget
    $padding: 3px
    $activeColor: $color1
    $inactiveColor: $color2

    padding: $padding
    /* ... etc. */

  .subWidget
    $padding: 6px

  .subWidget2
    $inactiveColor: $color3
    /* ... and so on */

With preprocessors, this doesn't work - you're better off defining a mixin that you feed variables into, which isn't the most intuitive approach. I hope this is adopted quickly by the major browser vendors. Unfortunately, writing your styles in this way will completely break in browsers that don't support it, in the absence of some sort of polyfilling JS or build tool.

dreamdu5t• 13 years ago

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

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

yuchi4• 13 years ago

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

sergiotapia• 13 years ago

Really ugly syntax.

    var-* ????

Who thought this would be a good idea?

byroot2• 13 years ago

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

thenerdfiles• 13 years ago

    data-*

is for attributes in HTML. It makes sense for CSS properties, syntactically speaking to map these two in terms of prefix-solutions.

intangible• 13 years ago

It feels like it's a passive aggressive way of giving us the finger (ugly syntax) while giving in to the obvious need for CSS variables we've been asking for since time eternal. http://www.w3.org/People/Bos/CSS-variables

tiquorsj• 13 years ago

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

joelthelion• 13 years ago

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

robin_reala• 13 years ago

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

yashau• 13 years ago

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

drinchev• 13 years ago

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.

meerita• 13 years ago

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.

yuchi4• 13 years ago

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.

simonrobb2• 13 years ago

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

yuchi4• 13 years ago

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.

simonrobb2• 13 years ago

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• 13 years ago

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.

CSS Variables in Firefox Nightly

Related Stories