I don’t want CSS to become a programming language, but I do want it to be a better declarative language. I would like to see variables added to the CSS Specification. People have been begging for Variables or Constants in various incarnations forever. Variables will help us do more with less code. It is time to make it a reality. I like parts of both the Glazman/Hyatt and Fantasai proposals, and I felt a blend of the two would be best for developers, so I wrote this specification.
I plan to submit the specification to the CSS working group and I’d love your feedback and comments. For those who have seen my wish list for CSS, yes, there are more posts like this coming, but it turns out that spec writing is monstrously difficult and slow, so I decided to publish incrementally. I have a new respect for the craft.
Comments
14 responses to “CSS Variables Specification”
This is probably the simplest spec for CSS Variables I’ve seen, and I like simple. However, I really do think variables proper and as they’re displayed here aren’t quite what’s needed for CSS to move forward in an elegant way.
I think CSS variables like this adds a layer of obfuscation to the language that obfuscates CSS more than it helps anything. And besides, none of the graphic artists I’ve worked with want variables, only the developers seem to want (or even properly grok) those. I think we could be best served by adding delegation capabilities, not variables, to CSS. (Background and further explanation behind the link.)
Interesting. There have been another proposed specification for variables: http://disruptive-innovations.com/zoo/cssvariables/
@Nicholas – I linked to that one. It was one of my inspirations. I liked parts of the fantasai spec and parts of the Hyatt/Glazman spec.
@meitar, I think we’re on the same page: http://twitter.com/andrewvit/status/16658608880
Not to say variables are a bad idea, having both approaches is possible. Variables in this sense are really more like constants: they can be generated server-side with tools like Sass, and their value is static as far as the browser is concerned.
Setting the style of elements based on the properties of others would be brilliant, though.
Why document.stylesheetVars rather than include the vars in a collection per stylesheet object, ala document.stylesheets[0].vars?
Variables would simplify things a little, but any real programmer would just code their CSS sheets in PHP or such.
What I’m really looking forward to is the ability to specify {width:80%-2em;}
Without that, you basically have to create a div at 80%, and then create another div with width:auto and a 1em padding.
[…] Stubbornella » Blog Archive » CSS Variables Specification […]
[…] 10. Nicole Sullivan […]
I’m in the variable camp. I want to keep the style confined to the CSS layer with a little flexibility to abstract common styles into variables. Once we start mixing styles into the server layer with PHP or even on the client with JS, we lose the clean separation of style and behavior/structure.
@Nicole, re: section 1.1.2 (Resolving duplicates via the cascade). In my work, I’ve dealt a lot with “base” styles and “client” styles, meaning the styles sheets that a customer might include through a wrapper or subsequent themeing on top of what I’ve built. It’s made me sensitive to avoiding clashes between my class names and the clients’ leading to heavy prefixing of classes e.g. .ez-col or .ez-vertical. It’s made me wish for wide @namespace support.
Do you think we’ll see @namespace support in the next 2 years (perhaps with IE9) and should this spec address that? You address @media. Would one be able to store variables in a @namespace?
@Jesse – there are already namespaces somewhere in the variables spec… Someone linked to it from here (or maybe on twitter?), but the spec made my brain melt. I need to try again.
@Meitar Totally with you.
Delegation would give you the best parts of variables (only having to specify properties once) without cluttering up the beautifully simple language that is CSS. If that weren’t enough, the idea of relationships that exist not just between parents / children / siblings, but between ANY elements is enough to make my mouth water.
I’d also like to see basic math added to CSS, but that seems like it’s already in the pipe in the form of calc() http://hacks.mozilla.org/2010/06/css3-calc/ The future’s so bright, I gotta wear shades B)
@Chad – I’ve gotten the impression that CSS is simple largely because of concepts like the cascade. Anything that breaks out of it vastly complicates what is possible, and what browsers have to deal with. delegation, for example, would allow contradictory (or infinite) expressions like this:
li { height: parent-height; }
I think most people want delegation for layout purposes, whereas they want variables to allow maintenance and modularity. For layout, check out the flexbox module. It gives you equal-height and any-order columns (not to mention good vertical alignment options).
Unlike delegation, variables (or constants; neither is entirely accurate) are safe. And Bert Bos’s argument that they are equivalent to a preprocessor is incorrect in at least one important respect: with a preprocessor you can’t override a global variable with a local one using the cascade. This is critical.
[…] 10. Nicole Sullivan […]
(Commenting a bit late, but still.)
@Nicole Sullivan: I like your proposal, but I didn’t understand if your variables were really variables or closer to constants. The section on programmatic access only shows how to get the value of a “variableâ€, and not how to SET it. So my guess is you don’t intend for full variables that you can change in JavaScript (which would cause the browser to keep track of which computed values are linked to a CSS variable and should be computed again when the variable change).
If your variables can’t be set programmatically, then maybe you should call them constants instead? That might help relieve the stress of implementors. 🙂
@Michael Kozakewich As someone already pointed out, there is calc() in CSS3 for what you ask for already. What’s more, your example doesn’t require you to compute the width… you could just use the box-sizing property and switch that element to a border-box model. Good news: there are several implementations of box-sizing already.