7 ms·
CSS Variables in Firefox Nightly
- kyriakos 13y agowould be nice if this eventually turned into something similar to sass or less
- bbx 13y agoCSS 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 13y agoThe 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/10164546.aspx http://blogs.msdn.com/b/ieinternals/archive/2011/05/14/10164...). However there are workarounds like @importing multiple style sheets.
- nawitus 13y agoI've found that nested rules are useful on almost every stylesheet. That, and variables, are the two main LESS features I use.
- mmahemoff 13y agoArguably 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 13y agoSometimes 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 13y agoBut 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.
- city41 13y agoI 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 13y agoSASS 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 http://cdpn.io/JoHAv
- chime 13y agoI 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 13y agoI 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 13y agoDoes 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 13y agoIs 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 13y agoThere'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
- yuchi 13y agoYou 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 13y agoBy 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 13y 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 13y agoWe'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_with_E4X https://developer.mozilla.org/en-US/docs/E4X/Processing_XML_...
- ozh 13y agosooooo much better than SASS or LESS which require additional tools that break workflow.
- ahoge 13y agoThey 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.
- city41 13y agoAdditional 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 13y agoIf your coding your CSS by hand, without tools like SASS\LESS, I would say you don't actually have much of a workflow.
- ape4 13y agoIs CSS Turing complete yet?
- ygra 13y agoThere was this: https://github.com/elitheeli/stupid-machines https://github.com/elitheeli/stupid-machines
- jccooper 13y agoNifty. 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 13y agoThe 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 13y agoIf 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 13y agoThey are not. The values can be redefined following the same CSS cascading rules as everything else.
- Drakim 13y agoBut 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 13y agoYes, 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 13y agoNo, 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".
- oddshocks 13y agoFINALLY people fixing the tools instead of creating wrappers around them! Thank you Mozilla!
- byroot 13y agoYep, 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 13y agoWow 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 13y agoUsing $ 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
- transfire 13y agoW3C 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 13y agoI 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/ http://lists.w3.org/Archives/Public/www-style/. Or were you being sarcastic? ;)
- city41 13y agoI 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 13y agoGreat, 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?
- pornel 13y agoPlease 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 13y agoThis 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 13y agoI 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 13y agoThis 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 13y agoThis is disgusting. "var-" prefixes!? No. Just no. Now there's another reason to use Rework, Stylus, LESS, or SASS.
- yuchi 13y agoWe're not talking about that kind of variables. CSS ones are a dynamic, inherited, cascaded (is that a word?) set of vars.
- sergiotapia 13y agoReally ugly syntax. var-* ???? Who thought this would be a good idea?
- deleted 13y ago[deleted]
- byroot 13y agoSomeone that did not wanted to generate syntax errors in older browsers ?
- thenerdfiles 13y agodata-* is for attributes in HTML. It makes sense for CSS properties, syntactically speaking to map these two in terms of prefix-solutions.
- intangible 13y agoIt 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 http://www.w3.org/People/Bos/CSS-variables
- tiquorsj 13y agoSass and less are really a kluge that just sheds light on how much CSS needs this built in.
- joelthelion 13y agoWhat's next? CSS loops? Why not make CSS Turing-complete while they're at it :)
- robin_reala 13y agoCSS (in conjunction with HTML) is Turing-complete: http://stackoverflow.com/questions/2497146/is-css-turing-complete http://stackoverflow.com/questions/2497146/is-css-turing-com...
- yashau 13y agoNote that you can also do this in Chrome/Chromium by turning on the "Enable experimental Web platform features" flag.
- drinchev 13y agoI'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 13y agoI 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 13y agoAs read on other comments: preprocessor variables have nothing to do with this kind of variables. Read the spec, they're a very powerful tool.
- simonrobb 13y agoI 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 13y agoOptions: - 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 13y agoPrepending 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 13y agoIt 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.