CSS Variables in Firefox Nightly | Hacker News Reader

CSS Variables in Firefox Nightly

hacks.mozilla.org

186 pointsdaw___67 comments

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>

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.

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

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.

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.

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

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.

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?

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

Many, but maybe (probably) not most.

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

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.

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

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

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.

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.

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

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;
    }

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.

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.

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.

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

Really ugly syntax.

    var-* ????

Who thought this would be a good idea?

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

    data-*

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

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

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.

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.

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

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.

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.

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.

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

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

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

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

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

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.

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

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.

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

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.

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.

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

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

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/

>all written in JavaScript

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

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

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.

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

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

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.

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.

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.

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.

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?

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

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.

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.

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

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

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

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

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.

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.

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

Is CSS Turing complete yet?

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

Reply on news.ycombinator.com