I personally favor smaller tools which do the least amount possible while still fulfilling your needs. That's why, for example, I'm not a huge fan of Rails, and would much rather use Sinatra when I can. I know I'm not the only one.
It's this sort of overhead I'm trying to avoid. Less is very straightforward, and I want to keep it that way—there's not much you need to learn to start using it, and the code base is tiny. For most use cases I think the feature-set will be more than enough, and if it's not, we have Compass.
Like I said, your current feature set is ample for the 95% use case of normal web development. To that end, we are in complete agreement.
I don't know how familiar you are with blueprint, but the less syntax doesn't support creating new abstractions that simplify design.
In sass using the compass port of blueprint we can do this:
#sidebar +column(8)
which generates:
#sidebar { float: left; margin-right: 10px; width: 310px; }
The column mixin is defined here: http://github.com/chriseppstein/compass/blob/master/framewor...
So what could be the equivalent less syntax for this?
div#sidebar { .column: 8; }
This is wonderfully easy for end users, but the language syntax has to become more complicated to support it. You have to be able to specify the arguments for the mixin. Also, you need a way to refer to the parent selector within the mixin abstractly. In sass we use the & symbol to represent the selector's context. I don't know what a "css-like" syntax would be for these capabilities. I would argue that they don't really have to be that "css-y", but they just have to play nicely with existing CSS syntax, because normal users don't need them.
Anyways, it's your project... But I've spent the last year thinking about these sorts of issues. If you want to discuss further, you can hit me up on github.
-chris
But less appears to make desperately needed additions that should ultimately show up in CSS itself IMHO. Certainly when I was first picking up CSS -- given my programming background -- I was reaching for the concept of variables and in fact was surprised that they did not exist in CSS. For that reason, I'd consider less to be more of a language extension than a framework.
CSS isn't complex, but building websites that work correctly in 8 web browsers most certainly is. Compass frameworks give you re-use without semantic fail.
I am loving it, especially since staticmatic has preview mode and compass has --watch mode - so I have both running and auto updating my preview while I work on it. Even if I didn't use haml at all and no framework (960), it would still make sense for sass variables and mixins with input variables alone.
building sites that work across browsers is easier with reset+some framework, but I still have to have IE7+ specific css, and compass seems a bit moody on windows.
edit: I am not sure if I would be comfortable using anything external to css to output css that has the same syntax, like less seems to have - it would most likely pollute my way of thinking down the road.
In your case, you don't use CSS frameworks at all, but you just want a few features that aren't in CSS, so Compass isn't what you'd be considering, Less or Sass would be.
Hopefully you don't take this personally. If I ever find myself required to use one of the above frameworks, they would probably be a lot more palatable when used in conjunction with compass.
Compass is libraries and tools to provide project management and community features, sass is the syntax that makes compass possible. Compass could be built on any css syntax with a comparable feature set to sass.
So my point was that until you provide those more heavyweight features in the core language, you cannot have a framework like compass. Frameworks drive adoption, so think about that decision carefully. Having powerful features doesn't force them to be used, but not having them, creates limitations.