Less is more
Hopefully you read my previous post about Sass and CSS preprocessors and felt my angst toward learning a new syntax. I’ve been using LessCSS for about a week and I’m really impressed. For starters, no new syntax to learn. This is simply an augmentation of existing CSS syntax. You get mixins, nested rules, and most importantly, variables. You also get operations but I’ve yet to find them that useful. Here’s my critique:
1) Nested rules are so natural. CSS should have worked like this all along:
a { color: #ddd; :hover { color: #999; } }
2) Compile time is pretty slow compared to Sass. This kinda sucks when you’re in a flow, needing to see a change and having to wait 4-5 seconds for the new file. If you install the TextMate bundle it’ll automatically compile on save which is handy.
3) Variables are worth every penny:
@borders: #ddd;
div { border: 1px solid @borders; }
That said, I wish they had taken into consideration David Hyatt and Daniel Glazman’s CSS Variable proposal since it’s probably the closest thing to future reality.
4) There doesn’t seem to be a way to access variables across imported stylesheets. I ended up importing a variables file on every page and my compressor removes the redundant generated styles but this is a temporary hack that I hope gets fixed.
5) Less really needs a decent TextMate syntax highlighter. I’m hoping to set aside some time this weekend to see if I can contribute to this.
6) While I would love to say border-radius: 4px; and have it compile with the -webkit, and -moz equivalent, the syntax enables enough abstraction so you can create the following mixin:
.border-radius (@radius=4px) {
-webkit-border-radius: @radius;
-moz-border-radius: @radius;
border-radius: @radius;
}
div { .border-radius(8px); }
Conclusion
This is the most intuitive preprocessor I’ve found. The syntax additions fit right in with native language and teaching it is a breeze. If you get the itch to contribute head on over to the Github
Related tags: css, lesscss, preprocessors, style sheets
Comments
Alex Gaynor http://lazypython.blogspot.com/
Several of your criticisms of Sass weren’t specific to it, but to any preprocessor. In light of those do you think you’ll actually use LessCSS, or do you merely think the ideas in it should be pursued as a part of the CSS standard?
Nathan Borror http://nathanborror.com/
I’m using it for the next release of Readernaut. I like the workflow and syntax a lot but I really hope the compile time speeds up.
Daniel
Nathan wondering if you have looked at Anthony Shorts CSSScaffold for this type of thing. PHP5 is required so might not fit your needs but it sure seems comprehensive. A few links for you: http://anthonyshort.com.au/scaffold/ http://wiki.github.com/anthonyshort/csscaffold
Jon Buda http://jonbuda.com/
Agreed. I’ve been loving Less for the past several months. Definitely my only big gripe is the compile time, especially for large files. Also, if you end up having deeply nested selectors, it’s rather easy to lose context. But overall it’s certainly well worth it.
Jeff Croft http://jeffcroft.com/
Less’s syntax, and the fact that it works with standard CSS files, definitely makes it more appealing to me than Sass. Still not sure I’m ready to integrate one of these into my workflow, but if I had to choose one at the moment, I’d go with Less. It just feels more targeted at CSS-heads instead of at hardcore programmers.
Chris Eppstein http://chriseppstein.github.com/
I’m glad that Alexis changed his mind about adding arguments to mixins. He was initially opposed to the idea, but they are such a nice way of abstracting away implementation details. However, from a syntax perspective I would have preferred the following:
This syntax is much more in line with existing css parsing rules and is going to work better with existing tools. Notice also that arguments to mixins are passed as key-value pairs instead of just values. I think this makes the code much more understandable to the casual reader who doesn’t quite understand what the mixin does and it also eliminates the need to remember the argument order and to only pass some of the default arguments.
Notice also that I am using $ to denote variables instead of @ which is used to denote directives. I think $ is a much more intuitive syntax addition to non-rubyists since it is used in perl and php and is less likely to create forward compatibility issues as the CSS specification changes.
Lastly, note that a mixin is mixed by using + instead of “.”. This is because that syntax implies class inheritance instead of just adding in the contents. I discuss the concept of class inheritance in great detail here: http://chriseppstein.github.com/blog/2009/10/12/css-class…
Nathan Borror http://nathanborror.com/
@Chris I don’t mind the mixin syntax. I like its simplicity. Keyword arguments would be really nice. Using the example in the post, something like:
Chris Eppstein http://chriseppstein.github.com/
@Nathan
I did some testing on IE6 and found that the parenthesis fail more gracefully than the curly braces (even tho they shouldn’t according to the css2.1 specification).
The use of curly braces with the mixin cause the parsing for the rules of the div selector to halt while the any rules following the parenthesis form are interpreted by ie6.
However, IE6 treated “.” and “+” the same, and as such, I vastly prefer + because it avoids confusion with class inheritance which mixins are not. Also, there’s no need for an @ sign in the argument passing.
Josh Nichols http://www.joshnichols.com/
Have you tried looking at Scaffold? http://wiki.github.com/anthonyshort/csscaffold
It has a lot of features SaSS does but the part that excites me is the Layout Plugin. If you check out the video demo linked above, at about 4:00 in, you’ll see that you can create grid systems like BlueprintCSS and 960 on the fly. :-) I would tolerate the learning curve if I could have the flexibility of Blueprint with my own custom grids.
Django Developers http://www.nuovolabs.com/
Although this might be helpful in some scenarios, I tend to think that CSS is not quite that verbose, and that it might be a waste of time trying to minimize it even more.
AvamnLomovene http://fjwerjrtpppioklioiooo.com/
http://fjwerjrtpppioklioiooo.com fjwerjrtpppioklioiooo <a href=”http://fjwerjrtpppioklioiooo.com “>fjwerjrtpppioklioiooo
Mhunter http://www.mp3hunting.com/
The problem with CSS pre-processing frameworks is that they don’t really fit within the average web designers’ work flow. Or they don’t mine, anyway. The other problem is that pre-processing frameworks are normally deeply entrenched in a particular technology, such as SASS and LESS being Ruby tools. All in all it’s a pretty good gem.