In order for these things to succeed it needs to adopt some for of standard and be available for all common server languages. Like CSS variables are part of the spec but could be used now with a server component.

If you serve CSS dynamically with variables on the server, then you would lose the benefit of stylesheet caching. To me, it makes more sense to define multiple classes in a static stylesheet, then change class attributes in the DOM as needed.

While I dig what these new abstraction layers are trying to do – I don’t like how they’re doing it. This “sort of like CSS – but not quite” syntax is awful. It seems like the different solutions are colored by the technologies they are implemented in syntax-wise (or maybe I’m just trying to hard to guess what they were thinking).

If you’re going to mix to syntaxes I’d want to be able to differentiate when one stops and another takes over. But the above mentioned solution would make my head hurt going back and forth between using these and writing plain vanilla CSS.

To me, these kinds of solutions would be more appropriate in some kind of IDE that compiles down to some combo of html, js, xsl and css (probably targeting a JS library like jQuery). HTML was originally meant to be machine written, so it would kind of make sense.

I’d actually like to see (and would be interested in helping to produce) an HTML 5 platform that let’s you target HTML 5, with maybe some extras like this kind of CSS abstraction and possibly even HaXe support for scripting – that will compile down to the HTML hack soup that we all have to deal with now by hand. Most HTML 5 features can be handled by Javascript and some CSS hacks – maybe a plugin here and there (audio and video), so I don’t see why not. Dean Edwards even made his IE7 and IE8 scripts, which to me are more than enough of a proof of concept.

I would love to not have to deal with hack soup any more, and just target HTML5. That would be awesome.

These libarys should ALWAYS work together with caching. So if you use it it will be translated once to a real css and put into the right place. If my css writing reduces to a half with an additional “convert-to-css” klick in my website it would be worth the effort.

I don’t see myself using something like this but hopefully the W3C CSS Working Group will take notice of the fact that no sensible person is satisfied with the crap that is CSS. Personally, I’d be happy if they’d just throw the whole thing out and start over with a fresh perspective but obviously that’s not going to happen. So what do we really need?
1) Variables
2) Math
3) Scope
4) Standard way to target specific browsers instead of using hacks
5) New ways of expressing things that are concise without being unreadable
6) A quick death for IE

Don’t know how I feel about that. Most of the things that people seem to say they want CSS able to do you can already with Javascript. Ah yes, people turn off Javascript, true. But if CSS becomes a scripting language then people might be tempted to start turning CSS off.

HTML5 is leaning towards being a programming language and now CSS? I guess things just are confusing and bloated enough for some people.

I, like many of you in previous comments, don’t get the real benefit of using a CSS abstraction library. What these achieve is great, but they all require the learning of yet another syntax just to produce what you can already do: static CSS.

I would, however, love to see a solution where browsers could understand other languages as “styling” languages. For example, consider the power of a JavaScript/jQuery based styling format, let’s call it JSS (JavaScript Style Sheets). This would cover all (or at least most of) the shortcomings of CSS, with support for variables, math, etc. Optimally, this could lead to smaller static (cachable) files for example. JSS could be an alternative, or complimentary technology to CSS, that is given the same status as CSS in the browser rendering process.

@WillPeavy – Calling them dynamic stylesheets is a little incorrect. Nothing here needs to be determined at runtime. It could easy be made static using a build tool or something.

For everyone else saying this kind of thing isn’t necessary – its only made necessary by the size or type of your project. I would say that the most important things needed are variables and calculations. Everything else here doesn’t really add functionality as much as offer a different syntax. I think that part is mostly personal taste.

Personally, I just use Velocity templates. Its really simple but effective. I can still use syntax highlighting and autocomplete from netbeans, but I can also easily do calculations and variables. It also lets me easily break apart my css into different files and concatenate using includes. However, the biggest win for me, is the ability to call into Java code. I built an image generator library that uses Java2d to create rounded corners, gradients, and other effects and put those and other icons into image sprites, and spit out the necessary css to make it work.

Constants: I run my CSS through a templating system if I want to do that kind of thing. The templating is already an essential part of my site framework, as it has been since I was using PHP3.

Concatenation: Meh, pointless.

Calculations: Done at time of templating, see constants.

–

Of all of these libraries, this is the least pointless and annoying.

Unfortunately the bar in this field is set pretty low to adequately reflect the pointlessness of it all, and so CleverCSS manages to win that title despite being still really quite pointless and annoying. All IMHO, of course :)