So I will be following along the development. There's still a lot of features that would be required of less to support a framework like compass. There's currently no arguments for mixins, no way to extend the language with functions that call out to code, no macro syntax allowing branching/looping and generation of selectors and properties. Such features aren't needed by your average user writing their own content, but they are absolutely core to building reusable design that can be configured and applied to your code using a simple and intuitive interface.

Anyways, it's really great to see new ideas and innovation in the css compiler space. We all win as these ideas mature and gain acceptance in the web development community.

-chris eppstein (sass core team)

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.

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.

(Someone needs to recognize these things and give praise to the people who so richly deserve it.)

Also a somewhat embarrassing one. My standard practice is to go to Wikipedia to find out what is going on, then back to the page to find out more. And yet, when I came across a good, helpful page, where that was not necessary, I didn't even notice.

I guess this is yet another example of good design being design you don't notice. (Although, obviously, that "you" isn't referring to you.)

This is just a simple enough extension to CSS that is natural, but still giving power to express styles much more concisely.

Chris Eppstein, the inventor of SASS has stated elsewhere that one of his primary goals is to make SASS friendly for designers to use, and he claims to have sought feedback from designers as well. See comments here : http://jeffcroft.com/blog/2009/may/20/applying-oop-concepts-...

Everyone seems to give designers an insultingly small credit for their ability to do development. But the concepts behind CSS and Sass are the hard parts (flow, positioning, block, layout, etc), the syntax is easy in comparison. Every designer that I've worked with who knew css took 1 hour to learn sass and fell in love.

</cynicism>

... looks like a good compromise of SASS though. I might jump!

Am I the only one in the world that bemoans naming decisions like this? The name is not just a dictionary word, and hard to get page rank with; it's even the name of an already-existing popular geek word (namely, the UNIX pager).

Am I the only one that thinks that the best names for things are the ones that have extremely few search engine hits before you choose them?

i agree that some names are ridiculous for search engines; this one might be ok. jury is still out.

I think it's better to name your software or site (or company?) something that can be searched for and found by the name alone.

I'm skeptical that augmented "regexes" are any more maintainable than compiler compilers.

http://www.usabilitypost.com/2009/06/16/introducing-less-a-b...

Allowing the mixin of any class into any class is genius. A very standard workflow when developing SASS stylesheets is extracting out a rule into a mixin, and mixing them into multiple classes. However, eliminating this step is huge.

I really like removing semicolons and braces, so SASS wins out huge in that regard.

I also really like SASS's new syntax for interpolation (standard ruby #{}). It's variable are lame though (use of the bang character for variables was a mistake).

Anyways, good stuff. I'm glad LESS exists and allows people to work around some of the missed opportunities of the CSS syntax.

The idea of allowing any top-level css class be used as a mixin is a really interesting one that we could consider adding to sass. However, I would argue that you still need an abstract class syntax like the current mixin, especially where arguments are in use.

As a sass framework builder, I really like that I don't have to define a presentational class name that would end up in your stylesheets just so that you can mix them into your semantic selectors. It makes it much easier to keep presentation out of markup.

Any plans to port this to other languages?

Or maybe LESS should be an acronym: Less Equals Simpler Styles :-)

I've often bemoaned the lack of variables in CSS for things like colors, especially because hex numbers are not very readable, but overall I'm not an advocate of these kinds of CSS pre-processors. It's not that I don't see the value, but I think they can easily become a crutch for developers who don't want to learn how to write clean CSS and utilize the cascade or refactor their HTML into a more sensible structure (hint: sometimes the most semantic class name is actually a presentational one, rather than duplicating a bunch of CSS, 'mixins' just serving to mask the smell).

The other thing is that cutting designers out of your project just because they can't or won't set up a Ruby environment is a pretty easy way to eliminate a lot of the best designers.

Its very similar to this, differences I see are:

It uses C/Lua, not ruby, so the cool kids probably wont use it.

Its compiled, so no interpreter needs to be installed.

Its very fast so it can be run as a cgi script, either for just development (avoiding the compile annoyance), or live (as its site uses now), or run from the command line to avoid the compile overhead in production.

You can add functions written in lua and compile them into the executable.

The variables are defined in a separate file, so your editor won't freak out in css mode.

When I introduced it got on smashing magazines best of whatever, http://www.smashingmagazine.com/2007/08/14/best-of-july-2007...

I had a lot of css hipsters hating on me... a lot. They despised it.

Their arguments were like "you don't need variables in css, you have to use the cascade!"

Something like

.my_colored_div, .my_other_colored_div { background-color:red }

... then way further down...

.my_colored_div { width: 100px} .my_other_colored_div { width: 200px}

So instead of defining something once, (a variable), you should define something (dom element) in multiple places.

I'm sure its obvious to you guys that defining something in multiple places like that would end up a big mess. So it didn't bother me so much being criticised by a group of developers who probably haven't done more complicated coding than a few pages of php.

Anyway, I'm not promoting moonfall, I honestly don't know if anybody is even using it, I never did, (although somebody ported it to a perl module), what I want to say is ever since that project that motivated me to develop moonfall, I haven't needed it, because the way I approach css has changed for the better.

I have a few simple rules.

1. Avoid using css, it relatively sucks. Try to let the html do what it wants. The more css you have, the more you will be fighting the browsers.

2. If you need variables in your css, you are probably making a big mess that you will regret.

3. If you have a web page that needs a lot of css, its too busy, or looks too much like a desktop application.

4. Only put global styles in the main css file.

4. My most controversial rule, one that has helped me the most but will probably bring on the hating... If a style only needs to be used in one place, or you cannot come up with a good name for it, don't put it in the css file, put it in the style tag attribute in the html style="blah:blahpx". Trust me, try it.

I won't even comment on the inline styles recommendation.

I just regret that it never got on my radar - I'm definitely going to test-drive it.

.header { background: @BACKGROUND } .maintable { margin-left: 5+@DEFAULT_MARGIN }

I mean, without it you are left writing it all manually! Good to see something open source though, and I love the hierarchy.

I say this as a disheartened Java programmer. I've recently been involved in a Rails project and a couple of Django projects, and then jumped back into Java. The difference in energy is amazing. Who would make something like this for Java? What would its success path be? Acceptance into an Apache incubator and then into "Commons?" Spec JSR-123987 finally being accepted by Sun/Oracle five years after its written?

I know this isn't a new revelation and I'm far from the first person to bemoan the stale, slow death of Java - but I'm sitting at an airport terminal with nothing better to do, and it's raining out, I'm depressed, and probably shouldn't be posting to HN. :)

I agree that most of the Java web bits (including pretty much all the popular web frameworks) are, for lack of a better term, enterprisey crap. It saddens me a bit that GWT isn't more popular - there's a lot of innovation and power there that gets ignored simply because the framework's written in Java. IMHO, Rails and Django et al are just kind of standard web MVC frameworks that happen to be implemented on fun-to-write languages: the only thing out there that has the real "right" approach to web _application_ dev is GWT, which is fundamentally difference from all the rest (per the Google Maps/Wave team, Wave would not have been possible without GWT).

The most "fun" Java web development framework, IMHO, is Stripes. I think what sets it apart is the lack of enterprisey crap - it's simplicity is refreshing, but it's still powerful enough to be useful.

It's true that Java has become utterly unfashionable. Unfortunately the popular replacements are very much limited by the fact that they are hundereds of times slower and force you into a multi process design in order to use multiple CPUs.

I've been trying really hard to replace Java in some projects and it's been really difficult, so I guess Java has got to have some quality beyond fashion. If you look for libraries that are well maintained, do non-trivial stuff that you don't want to do yourself, are fast, reasonably complete and up-to-date on Unix and Windows, you will find that 98% of them are written in Java or C.

  #header, #footer {
      /* styling here */
  }

Not to mention, having arguments for mixins is really, really nice. And compass is solid too.

I don't see why not. Most developers depend on tools written in a variety of languages.

  sass -h
  Usage: sass [options] [INPUT] [OUTPUT]

  lessc -h
  usage: lessc source [destination] [--watch]

Less fills a good, important niche by being very close to CSS while adding the core features that most people long for when working with it, and I will certainly use it in some situations. But Sass and Compass are both perfectly usable in non-ruby projects. Currently I'd argue Compass is more portable than Sass, both because of certain features (its --watch option that it shares with less, but, afaik, sass itself doesn't have) and its primary function, which is making CSS frameworks much simpler and more powerful.