Native CSS Variables: Welcomed Addition or Huge Mistake?

Native CSS Variables: Welcomed Addition or Huge Mistake?

The web development community received some big news recently. While not yet in the nightlies, experimentations are, once again, underway, which will, if successful, provide us with native support for CSS variables, mixins, and modules in browsers. The question is, though, is this a good thing?


Pros

  • Maintain projects easier
  • Write less “code”
  • More streamlined integration with JavaScript
  • Update site-wide settings and params with a single value change

Cons

  • Should CSS be complicated?
  • Higher barrier of entry for designers
  • The current proposed syntax will seem too confusing for some

How Does it Work?

Before we progress, keep in mind that these developments are still only in the experimental stages. They have not been implemented in any browser just yet.

If you’re modestly familiar with CSS preprocessors, like Less or SASS, you’ll have a basic understand of what to expect from these additions. (That said, the proposed syntax unfortunately is a bit different.) In the future, you’ll have the ability to create variables (global and local), and mixins, which you can think of as a collection of stylings that can easily be referenced.

What Took So Long?

As long as I can remember, the community has been clamoring for CSS variables; so what was the hold-up? In a word: disagreement. In fact, back in 2008, webkit was toying around with this feature — even to the point of implementing it into the nightlies — though, the proposal stalled not long after. Many felt that morphing CSS into a more programmer-like language would only introduce frustration; some even felt that it might confuse designers. For example, if the primary color in your project is stored within a variable — presumably at the top of your stylesheet — it would then require the designer to refer to two locations.

@myColor : red;
/* Less syntax */
#someElem {
 color: @myColor;
}

While this argument is valid to some extent, it doesn’t hold much weight. Most designers maintain a set of site-colors at the top of their stylesheet, which they use for reference. Introducing variables to contain these values is a logical solution.


The Proposed Syntax

Less or SASS fans will be accustomed to defining variables like so:

 
/* Less */
@primary_color : red;

/* SASS */
$primary_color : red;

The proposed syntax complicates things a bit by making variables typed. For instance:

/* Declaration */
 @var primary_color color red;

/* Usage */
body {
  color: var(primary_color);
}

Worth Noting

  • All variables are prefaced with @var
  • Variables are typed. Note the use of the color keyword in the code above.
  • To access the value of this variable, we use the var function, and pass in the variable name.

I must admit: it does seems a bit redundant to use the @var directive. The syntax that SASS and Less uses seems more appropriate and cleaner. @myVar is more succinct than @var myVar.

Variables types are a welcomed addition, on the other hand.

Variables are typed. Every primitive value type, every property, and a few extra convenience types exist. This lets us expose the new CSSOM stuff on them: document.styleSheets[0].vars['primary_color'].alpha = .5;
xanthir.com

Local Variables

Variables will also have the ability to be scoped to a declaration box, via the use of the @local directive. This can be useful when a variable only needs to be used once or twice within a project.

.box {
  /* Declaration */
  @local box_gradient background linear-gradient(top, black, white);

  /* Usage */
  background: var(box_gradient);  
}

Mix-ins

Mix-ins can be incredibly helpful. In fact, we covered the process of creating a class file of mix-ins not long ago on Nettuts+. You can read about it here — though keep in mind that the technique(s) presented in that article rely on on the Less preprocessor. The new experiments, again, use a slightly different syntax.

/* Less */
.border-radius( @radius: 3px ) {
  -webkit-border-radius: @radius;
  -moz-border-radius: @radius;
  border-radius: @radius;
}

/* SASS */
@mixin border-radius($radius: 3px) {
  -webkit-border-radius: $radius;
  -moz-border-radius: $radius;
  border-radius: $radius;
}

/* And possibly the native solution?? */
@mixin border-radius(radius length 3px) {
  -webkit-border-radius: var(radius);
  -moz-border-radius: var(radius);
  border-radius: var(radius);
}

Note the similarities between SASS and the proposed native solution for mixins. This is due to the fact that members of the SASS team are serving as advisors.

Nesting

As you may be aware, Less and SASS allow you to nest selectors. This can drastically reduce the size of your stylesheets, as it’s removes the need to the same selector repeatedly.

/* The current way */
#content { ... }
#content p { ... }
#content p a { ... }
#content p a:hover { ... }

/* Less and SASS */
#content {
  ...
   p {
      ...
      a {
         ...
        &:hover { ... }
      }
   }
}

/* And natively?? */
#content {
   ...
   @this > p {
      ...
      @this > a {
         ...
         @this:hover {
            ...
         }
      }
   }
}

While the proposed syntax is more wordy, to its credit, it does have a nice OO-like syntax, which will make plenty of developers feel right at home.

But remember – not all designers are developers.

Namespacing

By default in Less, all variables are — for all intents and purposes — global. As a result, it becomes difficult to distribute code, as existing variable names can be over-written. The potential native solution will be to implement modules, or namespaces. They can then be included in a block by adding the @use directive.

 @module Site {
   @var primary_color color #292929;
   @var secondary_color color blue;

   @mixin border-radius(radius length 3px) {
      ...
      border-radius: 3px;
   }
}

/* Incorrect Usage */
body {
   color: var(primary_color); // Variable name is undefined
}

/* Correct */
body {
   @use Site;
   color: var(primary_color); // #292929 (Works)
}

Conclusion

As noted at the beginning of this article, the documentation listed above is still in the experimental stages. It’s possible — likely even — that the syntax will change, based upon your feedback. So let’s have it. Does the idea of native variables in mixins in your CSS excite you…or scare you?

Me? Well I’m for it. I think the proposed syntax could use a bit of work, as it will no doubt scare away the designers among us. That said, if the syntax was simplified a bit, I’m 100% on board. How about you?

Note: Want to add some source code? Type <pre><code> before it and </code></pre> after it. Find out more
  • edwinhollen

    YES!

    CSS variables will assist advanced developers, and less-advanced developers can choose to not use them at all. There are so many instances where a dynamic native CSS variables could offer great assistance.

  • Ciwan

    I welcome it.

    I think it is a great idea. I’ll be looking forward to Tutorials on how to use these new features of CSS.

  • http://www.diigital.com Mike

    “While this argument is valid to some extent, it doesn’t hold much wait.”
    That should be doesn’t hold much weight.

    I think color variables at least, are a good idea. Things could get a bit referential if it were overdone (the definition always separate from the usage), but the commonly used colors would be helpful. The less verbose the syntax the better (within reason)

    • http://www.jeffrey-way.com Jeffrey Way
      Author

      Yeah – you’re right. Just a typo. Fixed.

  • http://www.marioplanet.com Zach

    I think this is a great idea!

    Although, I do admit I think I’m a better developer than designer, so I’m slightly biased.

    However, this “complexity” is rather minimal in my opinion.

    Also, it doesn’t need to be used if the designer isn’t comfortable now, right?

  • Matt Thornton

    Hey Jeffrey, any word on whether the proposed standard will support math on units and colors? I find that to be one of the most powerful things about Less.

    • Justin Long

      In the slideshow that this was presented with, he specifically called out the ability to use JS with the browser to get the sizes, namely document.styleSheets[0].rules[4].left.px == ’5′;

      If you were talking about math WITHIN the stylesheets, I can’t remember which module, but there is a CSS3 piece that allows you to do math in it.

      I’m not sure if that module is still getting recommended, though (moz had the first partial implementation in it, webkit hasn’t even started)

      • Matt Thornton

        Thanks Justin. The slideshow wasn’t loading for me the other day.

  • John

    I think it’s a great idea. I agree, the syntax could use some work, but I like the idea of variables in my CSS.

  • http://kenneth.me Kenneth Nordahl

    I reckon it’s a great idea. CSS will still be easy to get into but you can shorten the code and get long needed functionality for the more advanced users.

  • http://daniel-salazar.com Daniel

    CSS variables would be great. Long overdue actually. You mentioned that the variables would provide “more streamlined integration with JavaScript”. How so? I’m just trying to figure out how that would work or what the benefit would be.

    • http://nathansweet.me Nathan Sweet

      So you could create a css variable that was specifically important to the functionality of a website, like a drop down menu. Instead of getting javascript to use some sort of selector to modify the display, height, color, etc of a given element when an element was moused-over, the css variable could be dynamically changed by javascript instead and it would automatically. That’s just a simple example.
      When it came to something like feature detection it would also be immensely useful, because as soon as javascript detected a feature or lack of feature it could simply alter a variable in css, which in turn could alter the entire css document, thus saving the headache of having to go class-nuts in css and in the html
      So you won’t see stuff like this anymore:

      <someElement id=”myElement” class=”certainFont certainColor customShadow customBorderRadius”></someElement>

      Not that anyone was really doing this before, but you get my point.

      • http://daniel-salazar.com Daniel

        I didn’t realize that you would be able to get/set CSS variables via JavaScript. Very cool. Thanks for the explanation.

  • Kirk

    This is an important web moment in my opinion. We’re on the cusp of collectively making a decision; namely, whether or not it is okay to cater to people who are “designers, not developers.” In my admittedly limited experience, designers are relying more and more on image creation and related software (I’ll admit it, I’m looking right at you Adobe) and fewer are learning even basic HTML and CSS, never mind Javascript. If this was implemented, it’d be a terse acknowledgement that we expect designers to learn how to program, and developers to be able to design, if needed. I personally support this, but I was a programmer before I started really getting in to web design. I can see how it would scare the hell out of some people.

    • Mark

      >>In my admittedly limited experience, designers are relying more and more on image creation and related software (I’ll admit it, I’m looking right at you Adobe) and fewer are learning even basic HTML and CSS

      In my limited experience, this is nonsense.

    • http://www.infinityspiral.com Chris

      Wow I hope that’s true. More job security for me when the automatic software messes stuff up they have no idea how to fix. Oh but blah blah blah doesn’t work in IE or IE6? Give it!

  • http://2helixtech.com Matthias

    I don’t understand the controversy. If a designer is intelligent enough to be ‘coding’ something in CSS, picking up variables is not much more difficult. Also, they would not be required which means they could be completely ignored if so chosen (obviously, working in a team environment or with someone else’s handiwork this isn’t always possible).

    Every time I have seen this topic brought up, nearly every sentiment was “why does this not already exist?”

  • http://ideasnetstudio.com Paulo Griiettner

    I like the idea, as I like and use Less in all of projects, but the one thing I like more about less is that it does not bring much complication for those who aren’t programmers… The way they are doing, will realy get some focus overwelmed… Why add ‘@var’… the symbol ‘@’ already does not represents that it is a variable???

    The beauty of less is that, at the same time it is simple, it is also, powerfull. They did not modify the way of doing CSS, they just simplified…

    Simplicity is the key here… they want to reinvent something that is already working.. and working great

    • Paul

      ” Why add ‘@var’… the symbol ‘@’ already does not represents that it is a variable???”

      @import and @media are not variables and they do have @ in front of them.

  • http://daniel-rauber.de Daniel

    I think CSS variables would be a great addition to the current possibilities. I don’t think that it would make CSS much more complicated, because CSS is pretty easy right now, and in my opinion adding some more possibilities like variables wouldn’t make it much more complicated. Moreover, nobody has to use the variables, it’s just like an extension for those who do work with CSS for a longer time and build great projects.

  • http://www.charty.net charty

    Native CSS Variables is a very good and useful idea!

  • http://newarts.at Drazen Mokic

    Oh my god, i see another needed workaround for IE -.-

    This would be awesome if supported by all browsers.

    • http://www.twitter.com/netblonde netblonde

      i agree, its a great step forward for CSS, but wont be widely supported for at least 5 years :(

  • Chris

    I don’t agree with the cons. It would be still possible to code “oldstyle” CSS. No designer needs to take the knowledge barrier for using these features. He can still do it without them.
    For the case of CSS he has to maintain but didn’t create himself: It would be like with foreign languages. You always understand more from people speaking a foreign language, than speaking the foreign language yourself. So I think with a couple of minutes staring at foreign CSS, every designer would understand it and would learn the “modern way” of coding CSS very fast.

  • Amir s

    Hey, well i see most people here thinks its great, yeah well thats probably because all of us are DEVELOPERS looking for possible ways to increase our efficiency, maintain our on going projects, easy our work, etc….
    :P
    lets put this article on PSD-tuts and see what the “other” guys realy think… hehe :)
    even though feels like its our call here, the developers.

  • http://markuszeller.com Markus Zeller

    I would like to have variables on top of a CSS to define only repeating values like margins, fonts and colors. It will for sure be much easier to read if you could include somewhat of a own named color palette.

    Variables should be really “stupid” and global, because the rest of it can be done in JavaScript very well.

  • http://indiqo.eu Maximilian Bartel

    I’d absolutely welcome it — especially variables and nested tags would be a huge improvement. However, while having a look at the syntax itself, less seems to be a bit more intuitive yet powerful at the same time.

    The experimental, official syntax however adds too much additional syntax to the code which isn’t really similar to CSS itself in my opinion.

    So from my point of view, adding new functionality such as variables, nesting and mix-ins would be a good idea but it should be kept as simple as possible at the same time so CSS doesn’t become too complicated.

  • http://www.musings.it Federica Sibella

    I love the idea to have variables in CSS too: as many before me said it will be very useful and if somebody doesn’t feel comfortable in using them, he/she can just avoid them.

    I just hope that every browser will support them and render the new code the same way, otherwise we should invent some other “progressive enhancement” workaround :)

  • http://www.paulouano.com/ Paul Ouano

    This is a very much welcome (and overdue) addition. But the syntax is unnecessarily complicated. Why not pattern it after Less/SASS, then improve upon it. Brevity, people… brevity.

  • Nox

    It’s not just variables, everything that is in LESS and more is extremely overdue. The concept of CSS is terribly outdated and primitive compared to other used languages.
    It promotes copy/paste, heavy duplication, magic variables … all the things that are unspeakable everywhere else.

    As for barrier – newbies just don’t have to use it, invalid argument.

    As for compatibility – screw IE, we can’t always wait and wait, that way it would never be implemented. The progress of web technologies is terribly slow as it is, also due to these compatibility nonsense

  • http://wayneashleyberry.com Wayne

    These features are going to be amazing.

    Designers don’t have to use them, but developers will certainly appreciate them!!!

  • http://ahermosilla.com Andres Hermosilla

    W00t – This is exciting! I’ve been using LESS and love it, so this is great news. I don’t think it will make CSS more complicated, I think it’s its just another necessary level of depth that gives developers/designers more power. Beginners will just start with the basics of CSS and that will be fine and with time learn more of the complicated aspects.

  • http://www.tiffany-jewellry.com tiffany

    Looking forward to it hurry out.

  • http://ollisalmu.com Olli Salmu

    The general idea is great!

    But as default I prefer the syntax with the least amount of symbols, so I am still for using normal styles and overriding them when necessary. I cant see how variables would achieve lesser symbols with the same functionality.

    Development is always good, just wanna make sure I dont end up writing more complicated syntax just to use variables.

    I could see this technique being worth using in a massive system website.

    anyway, keep up the good work!

  • http://nicholasorr.com Nicholas Orr

    As long as regular CSS syntax doesn’t change then I don’t see the barrier to entry if you are a designer…

    As a developer and user of sass, variables + mixins = awesome.

    be really neat if we can change the variables at runtime with javascript, imagine being able to change the site colour on the fly by changing one variable! (assuming all other colours derive from this base colour, say you had a red accented site and wanted to dim the lights for a moment, that is a lot less code if you only have to tweak 1 or 2 css variables)

  • http://www.nouveller.com/ Benjamin Reid

    I’m all for it, the sooner the better in my opinion.

    My only concern is browsers that don’t support something that is one of foundations of a website. If you’re having to provide an entire stylesheet to fall back on if the browser doesn’t support it, LESS or SASS would be better than native support.

  • http://davgothic.com/ David Hancock

    This is long overdue! Overall it will mean writing less ‘code’ in a more DRY fashion.

    No doubt some designers will oppose it, but they don’t have to use the new syntax.

    The syntax would definitely benefit from being more like LESS though.

  • Dieter

    I’m pro variables, but definitely not the way suggested. In my opinion (and some others I see) the new syntax sucks big time and CAUSES complexity.

    LESS is founded by those who needed a cleaner / quicker way of coding CSS. Why don’t they just listen to those bright minds who are right at the front of development!

    I really hope LESS will be leading in the final syntax once implemented in all browsers.

    Just like jQuery… write LESS do MORE ;)

    • http://about.me/mikeschinkel Mike Schinkel

      Dieter – I thought the same about the syntax, until I read this http://www.xanthir.com/blog/b49w0 and came to understand why they are proposing it they way they are. So it seems the added complexity provides added value in Javascript that even LESS can not provide.

  • http://twiter.com/teddyzetterlund Teddy

    The syntax etc. might not be the best at its current state. Other than that, it’s an addition we’ve been waiting for a long time now. It’s opt-in to use, so I wouldn’t say it adds complexity for beginners, etc. and it’ll help a lot with code organization and tidiness.

  • http://www.ferdychristant.com Ferdy

    Very cool, I have been waiting a long time for this. And I suppose I will need to wait a bit longer before it can be used, but I am excited. I have to say that I really do not agree with the “cons”.

    Why? Well, because CSS currently is not simple. CSS is complex. It is. Sure, it is easy to learn how to style a few colors here and there, but styling a large visually complex site that works across browsers using maintainable, reusable CSS is very hard, and very verbose. I figure it will only become easier and much less verbose if the technique in the article is used.

    And as for the syntax, I think it goes too far to label this as a developer’s domain. It is more of a logical data structure than actual real programming Designers who are used to hand-coding CSS will have no problem picking this up. Designers doing PS templates only won’t even know. The few that hand-code CSS and find this too complex simply need to learn this like we all do, or continue to use the old ways.

    I can’t see a single con. I do agree that the syntax could be shorter.

  • http://www.veare.net Lukas Oppermann

    It sounds all very nice, but I am actually not totally convinced. My main point of unease is the processing speed. Will using variables slow down web pages? I am doing everything to optimize my code and speed up my pages and do not want fancy features to get into the way of fast loading web pages.

    Does anyone have any information concerning speed?

  • LC

    A simple implementation of variables is missing since always. I can’t believe we’re still waiting for it after more than 10 years.

    But we finally got rounded corners, shadow etc so, never desperate !

    Maybe I’ll try that LESS thing, eventually.

  • http://www.chimply.net Dieter

    It’s good that they’re working on it but it will probably take at least another 5 to 10 years before it becomes standard. Browser devs are holding technology back!
    The other day I was surfing a MS website in FireFox and it had a banner on it that said that I was using an outdated browser and that I should download IE8 instead… really made me laugh and mad at the same time. How can they even think IE8 is better than FF, Safari or Chrome,… The nerve! And where’s IE9 btw? I’ve been hearing about this thing for over a year now. What’s taking them so £€!$%#§ long?!?

    All browsers should update weekly to the latest technologies available! Today I read about the fact that they’re working on variables in CSS, next week all browsers should update automatically to support this feature… Users wouldn’t even need to see the update, it just happens in the background…
    No more FF4, IE9, etc. only FF-X, IE-X until forever.
    I guess I’m just too far ahead for my time…

    I am a developer not a designer and find the current way of working in css sometimes illogical. I don’t think variables would make css to complicated at all. If you can’t handle them, get another job.
    Things that as a dev bothered me in css were:
    - a none floated element doesn’t resize to it’s contents when it’s children are floated… why not? content = content?!? To me it doesn’t make any sense.
    - making an object center vertically… why isn’t it just a basic 1line setting for all element-display-types? center parent, center screen, center document, center whatever…
    - when you give an element a width of 100px and a padding of 10px the width will become 120px instead of the 100px you set it to be… why? padding is on the inside so it shouldn’t affect the space an element requires.

    Hopefully the variables are a start for a more logical css-code in the future. I honestly don’t think the original CSS language was created by a programmer…

    Thank you for the article Jeffrey.

    • http://nodecms.org/en Alexander Trefz

      Floated Element Content: display:inline-block is your friend
      Vertical Alignment: take a look at the FlexBox Model(currently revised)
      Box-Model Issues(Padding + Width): take a look at box-sizing

  • http://nicolahibbert.com Nikki

    I think the syntax needs a bit of a rethink, I find Sass to be much cleaner than what is proposed. Also, I’m wondering what the performance impact will be?

    • http://nodecms.org/en Alexander Trefz

      Performance Impact? This will allow a much better Performance! For example for the Selectors, the browser dont need to look at every singe selector as its own but (if nested) can use existing querys to do its stuff, its a performance boost! Also, the JS-Interface will allow much more responsiveness while doing JS-Animations because there is no String-Parsing more. On neither end.

      • http://russelluresti.com RussellUresti

        Evaluating variables would take additional computation time. And the nesting may not necessarily be a performance enhancement. For example, while ” #myIdElement .myClassElement ” may be more specific than just ” .myClassElement “, it is slower in performance, because CSS is evaluated right-to-left. The browser will first find all of the .myClassElement tags, and then do another query to see which of those are inside the #myIdElement tag (as opposed to first finding the ID element, then searching inside it only).

        There’s a chance nesting could perform the same way, querying inside-out instead of outside-in. Let’s take this nesting example…

        #myIdElement {
        .myClassElement {
        a {
        color: red;
        }
        }
        }

        Outside-in querying would start with first grabbing #myIdElement tag, then only grabbing the .myClassElement tags, and then only the anchor tags in those elements. However, it could query inside-out, meaning it would first grab all the anchor tags, then filter out any that aren’t in .myClassElement tags, then filter out any that aren’t in #myIdElement tags (this is the way CSS currently works as you make a selector more specific). So, in this case, each layer of nesting would cause a performance hit to your site rendering.

      • http://nicolahibbert.com Nikki

        Yes, performance impact – how long will it take to parse css variables and evaluate them?

        Also, are we going to see fragmented/incomplete implementations? Are we going to have to have one stylesheet for browsers that support the spec and one for those that don’t?

  • http://benjamincharity.com Benjamin Charity

    As to the concern of difficulty to non-programing designers: simply because variables are an option doesn’t mean they MUST be used, correct? I’m sure there are some designers out there who have yet to master CSS gradients and I’m sure they are still able to successfully complete a Cascading Stylesheet.

  • Patty

    Good idea, horrible syntax. If this would be the final syntax I would certainly stay with LESS.

  • Stephane

    Personally I’m not in favor of variable in CSS. CSS is a declarative language not a programming language, variable add a complexity that can be better added in a programming language like JavaScript or php.

    As for the proposed syntax, although it does looks long, the @ symbol is already used (@media, etc) so it seems to be a better implementation to have the @var declaration, it goes with what’s already in place.

    Yes I’m a designer who codes and no I don’t want to learn to program to be able to design. The visual part of a website should be made by a designer and no designer I know want to learn to program to be able to design a website, that’s why most don’t even want to leave Photoshop. Adding a level of complexity will drive even more designer to leave the front end coding to a programmer which is wrong in my opinion

    • http://russelluresti.com RussellUresti

      The important thing is that none of the already in-use CSS is being removed. These new features would be completely opt-in. If you want to use a variable, then you can. If you don’t want to, you can still assign the CSS properties the way you used to, without variables, without mixins, without nesting. There is no added difficulty to impact the barrier of entry.

  • http://www.lastrose.com Gabriel

    While i do like the concept, I don’t at all like the implementation. That combined with Less, SASS, php and other existing ways of doing similar stuff, I don’t think that it will take off all that much unless it can offer something that really sets it apart from all the other solutions.

  • http://www.darkhousemedia.com Adam Jackett

    I’ve been using CSScaffold for a while, and I’m starting to convert over to LESS.js – variables are nice, but mixins and nesting has increased my productivity a lot, and just makes sense. If the decision is made to natively support these features, that’s great, but if not I’m perfectly happy continuing to use 3rd party solutions.

  • http://www.kiljadn.net Nick Mason

    While I like the idea of it, and agree that it’s long overdue – I’m not too sure about this verbose implementation.

    For me, the idea of CSS variables carries with it the idea of saving time and file space. Less and SASS are great because they get you to the point you want to get to with the shortest amount of characters typed. This native solution seems a bit… excessive. Why take 30 characters to define something when I can take 5, for example? Brevity, for me at least, is key.

    To argue the point of it being an increased barrier to designers – I’d point out that most designers doing web work now are also at the point where they’ve got to learn one of the major JS libraries in order to stay competitive, so they are going to have to become familiar with OOP principles at some point. Generally that point is going to be sooner rather than later. I also say this as a designer who has found himself more and more in development roles – working directly with developers on a daily basis tends to give you a much different perspective, and there’s a lot to be learned from their workflows.

  • Fidzy

    Nice article, thanks.

    I am one of those who would like variables in CSS but never eared of LESS nor SASS. This is very interesting.

    Unfortunately, I already foresee my already hearless designer try to remove more of these. :-)
    Unless his favorite creation tool create the code for him…

    In the end it will fall to me to convert is CSS .

  • http://www.aplaceformyhead.co.uk Matt Fairbrass

    I personally think its a great idea, as it means we can define commonly used variables, such as those used in a colour scheme throughout a website, and refer to a common name for each of them, instead of having to remember their rgb, or hexadecimal counterparts.

    As song as the implementation of variable names remains clean and simple so as not to complicate CSS documents and raise the learning curve for designers, I think this is a positive development. I personally look forward to reading some tutorials on here.

  • Martin O’Reilly

    In my opinion, and as many have already said, variables, mix-ins and nesting are all long overdue for native support in CSS.

    The idea that it might scare people off is invalid as these additions would be classed as advanced techniques and not a requirement to use the language. I can see people groaning at having to re-write their entire stylesheet too, which is not the case. The idea would be to optimise any new developments.

    I have recently started to use SASS and it is great. The syntax is easy to pick up, clear and simple. There are also basic frameworks out there with helpers, common defaults and mix-ins to combine the standard/webkit/moz declarations which makes some of the newer CSS 3 declarations easier to implement. I have no doubt the same frameworks will be adapted for the native solution too which would further negate the complexities of these CSS additions.

    Looking at some of the syntax proposed I would argue that it is being over complicated but I am sure the developers have valid reasons. That said, if SASS and LESS users (currently the most popular options) aren’t demanding it, is there really a need. I agree with future proofing but there’s no point in reinventing the syntax if there is a standard people are already using.

    I totally agree with the article that @var is redundant and in my opinion is inconsistent for the language. It should be ‘@’:
    # – id
    . – class
    @ – variable

    Browser support would be the biggest issue for me. There’s no way I want to make all these new rules in my stylesheet and then have to go and do it all again the old way for browsers that do not support it. With SASS the rendering engine outputs pure normal CSS so this is not an issue.

    I would like to think this wouldn’t be an issue for modern browsers as if this is the way the community moves the developers of modern browsers would all provide support for it quickly for fear of losing market share. As a catch 22 it’s the user that suffers during the transition, and clients do not like it when users have poor experiences and so it comes back to the developers to provide backwards compatibility. Thus because things still work users do not upgrade.

    So the biggest obstacle for these developments is backwards compatibility. As it is, I don’t see how this will progress unless we cut support for older browsers (no) or do double the work (no). The only part solution I can think of is a Javascript parser on a CDN that is loaded dependant on browser support.. not very clean at all.

    Thanks for the article and asking for the feedback Jeffrey.

  • http://matt-bridges.com/ Matt

    Wow! This is huge! I have been looking forward to something like this (as we all were, I’m sure) for a long time. This could be incredibly useful to advanced developers without making it more difficult for designers (since they can ignore them).

    As usual, this is a great post, Jeff!

  • Ben

    Holy shit i’ve been waiting for this for years

  • http://812studio.com benjamin

    I’m curious to know if you have been keeping up with CssScaffold (now just Scaffold). I’ve been using it since your screencast covering how it works back in early 2010 (thanks). Anthony Short points out that the variables extension is based on the spec proposed by Nicole Sullivan for CSS variables. This spec puts the variable issue into perspective.

    Overall I think that variables are good. CSS is growing up and becoming more powerful, and so are the tools for writing it.

  • Ali Baba

    This is pretty cool. I can see new job type will be created CSS Developer. Of course how slow web standards is gets approved and IE issue I only can see this fully implemented maybe in 2050. Funny part the CSS3 and HTML5 is not even fully implemented and they pushing CSS variables.

    • Nuruzzaman Sheikh

      You are too slow. Please watch some sci-fi movies it’ll better help you to understand the possibilities of time.

    • Nuruzzaman Sheikh

      Don’t think the world slow as of you.

      Watch some sci-fi movies it’ll help you to advance your imaginations.

  • Nuruzzaman Sheikh

    I’m feeling great for its native support in browsers.

    Sometimes I feel scared when I have to type over 2K lines of CSS and I think if I could do it like a programming language. Now it is time for waiting for that great day when all future browser’ll support native CSS variable. And I hope that day is very closer to us as this is the want of time and generation.

  • http://russelluresti.com RussellUresti

    I like the initiative, mainly because it builds on top of CSS instead of replacing anything. The worry about creating a higher barrier of entry would only be valid if the old method no longer worked, but you could still build a site using CSS without variable, mixins, locality, or any of these new features.

    Hopefully, they’ll implement the SASS/LESS syntax — it would be dumb to implement features of other libraries without taking the syntax that those developers are used to.