

Less, a leaner CSS - cloudhead
http://lesscss.org

======
chriseppstein
This looks promising and seems to address a lot of the objections I hear to
compass and sass. I do really like the superset syntax approach where css is
legal syntax in a less file.

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)

~~~
cloudhead
Great to have you on board! Compass was definitely one of the inspirations
behind Less. Unlike Compass, though, I'd like to keep it small, as it is and
as close to CSS as possible, so the more complex features of Compass probably
won't find their way in Less, unless they fit the ideal.

~~~
chriseppstein
I know the distinction between Sass and Compass is blurred for many folks,
much like ruby and rails.

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.

~~~
cloudhead
'Having more features doesn't force them to be used' — correct, but it changes
the perception people have of the tool, as well as what they start to expect
from it.

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.

~~~
9oliYQjP
I think you made the right call. CSS isn't complex enough to need a framework.
In a lot of cases, CSS frameworks abuse the primary motivating factor for
trying to separate style and content in the first place. If I have to use
particular HTML markup or class naming conventions, I may as well just forego
the separation of content and style altogether and use table layouts.

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.

~~~
chriseppstein
You don't know about compass then. Go watch the screencast.

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.

~~~
9oliYQjP
I do know about compass, but I have a feeling compass will be to less what
Prototype is to jQuery, at least for me. When I first learned Prototype I
thought it was awesome, but jQuery just ended up making a whole lot more sense
to me. Different strokes for different folks I suppose.

~~~
carbon8
What you are describing would be closer to Sass vs Less, not Compass vs Less.
Compass is a meta-framework built on Sass to make working with CSS frameworks
much simpler, easier, cleaner and more flexible.

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.

~~~
chriseppstein
At least someone gets it ;-)

~~~
9oliYQjP
If I don't want to use a framework like blueprint, and I actually prefer (in
this context) the CSS syntax (e.g., braces et al) as opposed to HAML, then is
compass still useful to me? That's what is (now) confusing to me given your
replies to my original comment. My original criticism isn't of compass. It's
just that if I don't like blueprint/YUI/960, then would it not be redundant to
use compass?

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.

------
sketerpot
That web page has shiny-excellent design. It immediately tells you what Less
is, how to install and run it, and then launches into source code examples so
you can immediately learn how to use it. Very smooth!

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

~~~
ggchappell
That's a very good point.

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_.)

~~~
ralph
"good design being design one doesn't notice"?

~~~
ggchappell
Yeah, that works. Also "good design being design that isn't noticed".

------
KevinMS
After suffering through a project with complex css I felt a similar itch and
tried to scratch it by developing <http://moonfall.org/>

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...](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.

~~~
henrrrik
Even very complex and messy CSS is easily handled using something like Firebug
for Firefox or the Web inspector in Safari.

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

------
ihumanable
Yes yes a million times yes. I've looked at Sass before but its HAML syntax
made it less than appealing. This is beautiful, its just a smarter CSS,
leveraging everything you already know about CSS but with the things you wish
CSS had.

~~~
jamesjyu
Totally agreed here. The reason I don't want to move to HAML and Sass is the
learning curve required of devs, especially those that aren't necessarily
familiar with scripting languages (like visual designers, etc). but do know
about HTML and CSS.

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

~~~
deepakjois
I think it is important to differentiate between HAML syntax and SASS. Even
though both are part of the same package, SASS syntax is actually quite
minimal and closely follows CSS syntax, without the extraneous syntactical
elements like curly braces etc.

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-...](http://jeffcroft.com/blog/2009/may/20/applying-oop-concepts-
css/#c150744)

~~~
chriseppstein
Hampton Catlin invented Sass. Nathan Weizenbaum is the primary maintainer now,
and I'm just a newbie, only around since Sass 2.0.

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.

------
Pistos2
Nice looking project, but...

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?

~~~
railsjedi
I like the name a lot, but I agree that its going to be difficult to google
search. Sucks, but doesn't that seem like a limitation of search engines?

~~~
diN0bot
search for "less css". hmmm. "less extend css" no problem.

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

~~~
Pistos2
Is that like how we "need" to search for: "flickr photo sharing", "wikipedia
encyclopedia", "facebook social networking", or "youtube video sharing"?

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.

~~~
george_morgan
This would be more of an issue if it was a consumer service/product. I'm going
to give web developers the benefit of the doubt and say they'll probably find
this if they're looking for it.

------
mrkurt
For once, I'd love to see one of these things built with a proper parser. The
regex madness has to stop!

~~~
gamache
Why? Sane regexes aren't all that inefficient, and here efficiency doesn't
matter much anyhow.

~~~
dasil003
It's not about efficiency, it's about robust parsing.

~~~
boucher
Actually, I think it's about ease of implementation.

~~~
stcredzero
Correctness > Ease of implementation

------
cloudhead
Also, check out the article @ usabilitypost.com for the full story:

[http://www.usabilitypost.com/2009/06/16/introducing-less-
a-b...](http://www.usabilitypost.com/2009/06/16/introducing-less-a-better-
css/)

------
russell
I like the look of Less. I've taken cursory looks at other CSS generation
tools have been less than enthralled by the ugly syntax and over-
complications. Less is lean and looks like something that might be a future
CSS extension. I'm definitely going to give it a try.

------
railsjedi
Sass definitely needs some competition. I love it, but there's some things it
could improve on.

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.

~~~
chriseppstein
We deprecated some features in Sass 2.2 that will allow us to change the
variable syntax in 2.4. Legacy users are a bitch ;-)

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.

------
cloudhead
Now if anyone feels like writing a tmbundle for Less, I'll be more than happy
to put it up on the site!

------
ssharp
This is outstanding. It's simple and logical. You don't need to learn any new
language. It doesn't "fix" CSS but it provides a lot of very useful features
to help clean it up. The nested rules and variables are really useful. The
mix-ins seem like they are already "sort of" available in CSS by just
assigning multiple classes to an element.

Any plans to port this to other languages?

------
dpnewman
This is a near perfect example of an incremental improvement. Kind of reads
one's mind about what would be ideal to add to css - and provides it in a
completely intuitive implementation. Bravo.

------
asifr
Mixins! Why has CSS not implemented these brilliant syntax rules? It's so
intuitive and fits in with any programmatic workflow.

~~~
sfphotoarts
Coming to CSS about 6 months ago I was just amazed that it doesn't have these
features already, like variables and mixins. Is there anything like this out
there already for PHP?

~~~
chriseppstein
What is it about php folks that think that everything has to be implemented in
php?

~~~
sfphotoarts
I'm not suggestion everything has to be implemented in php, however, I'd have
thought the answer was pretty obvious in this case. FAIL!

------
ori_b
It seems slightly odd to call it "leaner" when you're adding stuff on top of
CSS. The additions seem nice enough, but to me, "leaner" means that the number
of [mis]features is being reduced to make a smaller spec and implementation.

~~~
benhoyt
Yes. And to me it seemed odd that 3/4 of the examples of LESS actually require
MORE typing than the CSS. So perhaps not the best name, but looks like a nice
tool.

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

------
timdorr
I find it interesting that these tools are targetted at developers when
designers could easily benefit from these even more. What would be interesting
is if someone could build this into a Javascript library that compiles and
converts the Less/sass/Compass code into CSS on the fly. If Cappuccino can do
it for executed code written in an entirely different language, I don't think
CSS would be that hard either. Of course, it's been a _long_ time since I
wrote a lexer/parser from scratch.

~~~
dasil003
I think the reason is because designers are not into complex toolchains. Just
the fact that you need to compile this CSS is a hurdle that makes this much
less usable in a designers world.

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.

------
heycarsten
I use Sass daily and I will continue to. I don't understand the hate for the
indentation sensitivity; no curly braces or semi-colons to deal with and
visible structure are huge wins as far as I'm concerned. I guess I'm just not
seeing the "obvious awesomeness" that makes this so much of an improvement
over Sass. I can see the appeal for the use case of existing CSS but I find
that rarely happens.

~~~
chriseppstein
<https://twitter.com/chriseppstein/status/2198875051>

------
trapper
Surely everyone has been using a homegrown version of this since they started
with css? We use a build script to generate our css files with things such as:

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

------
jonursenbach
This is ridiculous. The first two examples they give you, you are actually
producing more code than if you had done it properly to begin with.

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

Less, in their case, is actually more.

~~~
pkulak
That's because they are trying to make simple examples. I've wanted this
functionality in CSS many times, and in my real-world CSS, it would have made
it a _lot_ easier and shorter.

------
RossDM
How come no one is making these things for Java? Do people just use Ant to do
the same thing?

~~~
mosburger
No one makes any stuff like this for Java. Java has lost the wind from its
sails. Java has been relegated to beige cubicles and enterprise solutions.

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. :)

~~~
revetkn
Check out GWT's CssResource support, which is a much more powerful version of
Less backed by a real compiler instead of a collection of regexes:
<http://code.google.com/p/google-web-toolkit/wiki/CssResource>

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

~~~
mosburger
I've never tried GWT. I'll be sure to check it out, thanks for the
recommendation.

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.

------
wfarr
It's interesting, for sure, but I like haml/sass and that style much more.

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

------
nex3
A follow-up: <http://news.ycombinator.com/item?id=662669>

------
ngrandy
for people who want to try out or develop with less without installing the
ruby gem, you can compile documents via http here:
<http://www.tripeedo.com/less>

------
PStamatiou
just as i switched to Compass/Sass...

~~~
chriseppstein
Well lessc is just a replacement for the sass compiler so far. It lacks the
project management and ruby framework integration features that you get with
compass and sass.

~~~
jmtulloss
For those of us not using Ruby frameworks, that's a definite plus. It's nice
to have a simple standalone tool that does this.

~~~
jeroen
Except that I doubt that anyone not using Ruby is going to install Ruby just
to run this. It looks very promising, but without a standalone compiler it is
useless to me.

~~~
carbon8
_"Except that I doubt that anyone not using Ruby is going to install Ruby just
to run this"_

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

~~~
jmtulloss
Agreed. I barely know Ruby, but I have Ruby installed cause so many quality
tools are written in it.

------
nopassrecover
Perfect

