CSS Variables in Firefox Nightly(hacks.mozilla.org)

186 pointsby daw___vor 13 Jahren67 comments

hacks.mozilla.org

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

22 comments

pornelvor 13 Jahren

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>

ssafejavavor 13 Jahren

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.

nfmvor 13 Jahren

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.

X4vor 13 Jahren

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

transfirevor 13 Jahren

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.

city41vor 13 Jahren

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.

Recoil42vor 13 Jahren

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?

simonwvor 13 Jahren

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

arcatekvor 13 Jahren

Many, but maybe (probably) not most.

airtonixvor 13 Jahren

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

risvor 13 Jahren

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.

jonathanhefnervor 13 Jahren

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

4thjulyvor 13 Jahren

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

qzncvor 13 Jahren

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

sergiotapiavor 13 Jahren

Really ugly syntax.

    var-* ????

Who thought this would be a good idea?

intangiblevor 13 Jahren

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

[deleted]vor 13 Jahren

byrootvor 13 Jahren

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

thenerdfilesvor 13 Jahren

    data-*

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

yashauvor 13 Jahren

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

dreamdu5tvor 13 Jahren

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

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

yuchivor 13 Jahren

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

oddshocksvor 13 Jahren

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

byrootvor 13 Jahren

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.

mekishizufuvor 13 Jahren

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

Drakimvor 13 Jahren

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.

jdmichalvor 13 Jahren

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

Drakimvor 13 Jahren

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.

jdmichalvor 13 Jahren

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.

Drakimvor 13 Jahren

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

jdmichalvor 13 Jahren

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

xuxvor 13 Jahren

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.

icebrainingvor 13 Jahren

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

simonrobbvor 13 Jahren

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

yuchivor 13 Jahren

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.

simonrobbvor 13 Jahren

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.

drawkboxvor 13 Jahren

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.

drinchevvor 13 Jahren

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.

tiquorsjvor 13 Jahren

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

meeritavor 13 Jahren

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.

yuchivor 13 Jahren

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.

joelthelionvor 13 Jahren

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

robin_realavor 13 Jahren

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

kyriakosvor 13 Jahren

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

bbxvor 13 Jahren

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.

crazygringovor 13 Jahren

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.

mmahemoffvor 13 Jahren

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

samwillisvor 13 Jahren

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.

prezjordanvor 13 Jahren

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.

cheapsteakvor 13 Jahren

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

city41vor 13 Jahren

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.

nawitusvor 13 Jahren

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

chimevor 13 Jahren

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.

randallvor 13 Jahren

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.

georgecalmvor 13 Jahren

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.

andreypoppvor 13 Jahren

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

yuchivor 13 Jahren

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.

camus2vor 13 Jahren

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.

danabramovvor 13 Jahren

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/

risvor 13 Jahren

>all written in JavaScript

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

erichurkmanvor 13 Jahren

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

ozhvor 13 Jahren

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

city41vor 13 Jahren

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.

nnessvor 13 Jahren

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

ahogevor 13 Jahren

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.

ape4vor 13 Jahren

Is CSS Turing complete yet?

ygravor 13 Jahren

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

jccoopervor 13 Jahren

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?