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

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.

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)

@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?

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.