Blogging And All That Malarkey

LESS

About two years ago, I tweeted “If your CSS is complicated enough to need a compiler or pre-processor, you’re fucking doing it wrong!” I meant it too. After-all, CSS isn’t hard to learn and it’s easy to write and write quickly. So why would you need a processor like LESS or Sass?

People reacted (as they do) telling me I was wrong. I wasn’t oblivious to their enthusiasm, so I pulled up the Sass website, ready to dive in. Wait.

First of all, let’s get Sass up and running. If you’re using OS X, you’ll already have Ruby installed. Windows users can install Ruby via the Windows installer, and Linux users can install it via their package manager. Once you have Ruby installed, you can install Sass by running gem install sass.

Sorry, what? Now you can berate me for not understanding the Terminal if you like, but I’ll trade your ruby gems for my under-colour removal and dot gain, any day of the week. How hard should this be? Really?

sass --watch style.scss:style.css
sass --watch stylesheets/sass:stylesheets/compiled

That hard. Obviously.

If you were watching Twitter that night, it wasn’t just the interface that was blue. Chris Eppstein was watching. He kindly offered to help, so I turned my Mac over to him and I watched as he remotely flew through Terminal commands and listened while he tried to explain why I couldn’t see anything that he was installing where I expected it to be — in my Applications folder. Boy did this seem like a lot of work. I just didn’t get it.

Nathan Borror didn’t think Sass was for him either. Not because he shared my Terminal phobia, but because CSS shouldn’t be so complicated as to need Sass anyway.

Why the frak do I need control directives in CSS? If I’m using a @for loop to generate styles I’m doing something very wrong. CSS is not a programming language, it’s a style language and the preprocessor community should keep that in mind.

Jeff Croft summed it up well, commenting on Nathan’s post.

There are a few reasons for this:

Most CSS gurus aren’t programmers. When they start seeing logic, variables, mixins, and other programming constructs in their style sheet, they freak out a bit.

CSS gurus are just that: CSS gurus. They already know how to write their way out of any paper bag you can find using CSS. They’re experts. They don’t need a preprocessor. Developers are writing these things because, for them, CSS is confusing and missing useful functionality. But CSS gurus don’t look at CSS that way. Most CSS gurus think CSS is, by and large, pretty darn great. Sure, we have little nits to pick, but for the most part, CSS works for us, and we know how to bend it to our will.

To the typical CSS designer, the command line is a frightening place.

Even a simple CSS guru knows that code generation reeks of inelegance (not saying Sass is inelegant or that there aren’t good examples of code generation … just that, as a concept, it scares people).

Fast forward to this summer. I’m now primarily working with clients in week long agile design/development sprints, so I need to be faster and have more flexibility when I’m writing CSS. With clients’ budgets squeezed, I also want to spend more time being creative and less reinventing code.

When Twitter released their Bootstrap it came with set of LESS files, which prompted me to take at LESS. A few days working with it and I was converted. These days I’d be loathed to work without it.

One of the reasons that LESS works for me is that — although I could use a Javascript or server-side compiler if I knew what the hell $ npm install less@latest meant — there’s several desktop applications that compile LESS files to CSS without me needing to go anywhere near a Terminal. (Sass has a desktop app now too but, not being a Sass user, I can’t tell you how well that works.) If you work on Linux or Windows, SimpLESS will suit you better. I prefer LESS.app because it minifies CSS and has an interface that’s clearer if not prettier than SimpLESS.

When I begin a project I start with a LESSed up version 320 and Up that includes a compilation of functions, mixins and operations from:

Plus a few of my own. (I’ll include my LESS files in the next release of 320 and Up.) Here’s just two of my LESS behaviours.

.font-size(@font-size: 16){
@rem: (@font-size / 10);
font-size: @font-size * 1px;
font-size: ~"@rem"; }

Converts pixels to relative em (rem) units and includes a fallback for browsers that don’t understand rem. I just write:

h1 {
.font-size(32); }

LESS outputs:

h1 {
font-size:32px;
font-size:3.2rem; }

I often use tints of just one or two, sometimes complementary, colours per design. I’ve been doing for years. LESS makes working with my colour palettes even easier.

@col : #468DB6;			// Base colour
@comp : spin(@col, 180);  	// Complementary colour

@Col_l1 : lighten(@col, 5%);	// Lighten base
@Col_l2 : lighten(@col, 10%);
@Col_l3 : lighten(@col, 15%);
@Col_l4 : lighten(@col, 20%);

@Col_d1 : darken(@col, 5%);	// Darken base
@Col_d2 : darken(@col, 10%);
@Col_d3 : darken(@col, 15%);
@Col_d4 : darken(@col, 20%);

@Comp_l1 : lighten(@comp, 5%);	// Lighten complementary
@Comp_l2 : lighten(@comp, 10%);
@Comp_l3 : lighten(@comp, 15%);
@Comp_l4 : lighten(@comp, 20%);

@Comp_d1 : darken(@comp, 5%);	// Darken complementary
@Comp_d2 : darken(@comp, 10%);
@Comp_d3 : darken(@comp, 15%);
@Comp_d4 : darken(@comp, 20%);

LESS outputs:

.col1{background-color:#5799be;}
.col2{background-color:#6aa4c5;}
.col3{background-color:#7cafcd;}
.col4{background-color:#8ebad4;}
.col5{background-color:#3f7fa4;}
.col6{background-color:#387091;}
.col7{background-color:#31627f;}
.col8{background-color:#2a546c;}
.col9{background-color:#be7d57;}
.col10{background-color:#c58b6a;}
.col11{background-color:#cd997c;}
.col12{background-color:#d4a88e;}
.col13{background-color:#a4643f;}
.col14{background-color:#915938;}
.col15{background-color:#7f4d31;}

Now I can switch base colours and create new colour themes in a second or two. It makes designing in a browser so much faster that I can hardly imagine why anyone still uses Photoshop for this kind of thing.

Although I’ve not discovered my perfect set of responsive design LESS styles yet, these have come close.

Paul Mist’s responsive.less
Tyler Tate’s Semantic.gs

It’s not all roses though. There are some LESS behaviours that I simply won’t use. Nested rules might look like time savers, but the time you’ll spend debugging specificity will soon use up any time you save.

While LESS is not particular about indentation and white-space, I am. When you work in a team — as I’ve been doing recently — unless you’re really careful about observing indentation and white-space conventions, nested rules will soon become almost impossible to follow. Nested rules promote bad practice too. The CSS they produce reeks of over specificity.

[role="banner"] {width:100%;}
[role="banner"] h1 {font-size:3.2rem;}
[role="banner"] h1 a {display:block;}
[role="banner"] h1 a span {opacity:0;}

This is clearly a case where your knowledge of what’s best should override using a tool.

Whenever someone talks about tools like LESS or Sass, the conversation can too easily turn to which tool is best. I’m not interested in that. What matters is that we find tools and workflows that work well for us. LESS works for me. In fact, it works so well for me, that I can’t imagine working on a project without it.

Like I said:

I once wrote that there was no need to use a CSS pre-processor like LESS or Sass. I was wrong. Very sorry.

Leave your comment

Neil Sweeney

November 7 2011 @ 01:23pm #

I found it a none existent issue before with CSS that I didn’t need to do variables and such like as I had a good management on my CSS file(s). But since I started developing significantly larger sites I found LESS to (almost) be a requirement to effectively manage style development.

But I come from a coding background so the move from CSS to LESS was extremely quick with anything being mentioned more than once becoming a variable and setting up some cool mathematical functions to change the layout of a site with real style. Plus, I love having a functions.less file =D

On a side note, the dude who wrote the LESS.app has done a new app now called Code Kit (http://incident57.com/codekit/) that compiles LESS and SASS but also Stylus and Coffee-script as well as concatenating JS files (plus some other cool features).

David Hund

November 7 2011 @ 01:24pm #

Nice writeup Andy. Like you I’ve gotten used to LESS. It seems to have the right amount of ‘sugar’ (helpful features) while remaining simple and CSS-like.

I’d be interested in seeing your LESS files.

A quick tip: if, like me, you enjoy working with Less.app you’ll probably love Codekit by the same developer: http://incident57.com/codekit/

Andy Clarke

November 7 2011 @ 01:27pm #

@Neil Sweeney @Neil Sweeney

I heard about Codekit just an hour or so ago. I’ll be taking a close look at it tonight.

John Faulds

November 7 2011 @ 01:38pm #

Less convert here too. ~~Just a small point: the link to Paul Mist’s responsive.less needs fixing.~~ Fixed. Thanks for the catch.

Charles Roper

November 7 2011 @ 02:14pm #

Definitely a #TeamSass member here. I would encourage everyone to try both Less and Sass before committing. One guy’s experience with both can be read here. I started my career as a print designer, worked as a web designer since 1996 (on and off), and consider myself to be a terrible programmer. I have never found the Terminal thing (or Windows cmd prompt thing) hard to learn. Learning CSS itself with all the cross-browser weirdness involved was much harder, especially when I learnt it in the late 90’s/early 2000s.

Also worth mentioning Scout, which is equivalent to SimpLESS and LESS.app.

Another really useful resource is The Sass Way. Well worth digging into.

My two favourite Sass features are probably @extend and Compass’s Spriting. Truly game-changing. The first time you use spriting in particular, you’re likely to exclaim, “holy shit, this is unbelievable.”

Aaron Russell

November 7 2011 @ 02:44pm #

Welcome to 2011, Andy ;)

Tongue out of cheek, thanks for writing this. I’ll be updating my own article.

The points you make about nesting are important. Less and Sass both make it too easy to get carried away end up with some pretty sloppy CSS, with over-specificity galore and lots of duplication. The solution for me is not to just not use those features, but learn how to use those features in a sensible and disciplined way. It’s not easy but when you get there it’s zen-like.

Paul Mist

November 7 2011 @ 02:50pm #

Andy, again thanks for the mention.

Would love to hear what would make for a perfect set of LESS styles for responsive design?

John Faulds - good eye!

Dave Gillhespy

November 7 2011 @ 02:55pm #

I used your tweet as part of my argument against switching to LESS on my team at work. The argument went something like this: “designers I respect also think it’s silly to use pre-processors.” I lost that argument and am glad I did. I now love LESS. I’m glad that we came to our senses.

Josh Nichols

November 7 2011 @ 03:42pm #

I tried Sass a long time ago, but the command line stuff was too much of a break in my workflow and I didn’t like the idea of a server-side processor, so I abandoned it.

Then when I found LessCSS app, I gave Less a try and now I have a whole set of my own mixins and can use CSS3 rules, with the various browser prefixes, easily and quickly. Gradients, box shadow, border radius, clearfixes are all things I can write once and let the processor do the rest.

It’s over. I can’t go back to regular old CSS now.

Ray Brown

November 7 2011 @ 04:28pm #

Overall, this is a pretty good writeup. Less and Sass are the future of CSS, and I’m really excited to be using these tools as they carve their place in web development.

Andy: You mentioned not using nesting in fear of ending up with too much specificity. When I started using Sass, my resulting CSS *reeked* of crippling specificity, and the whole concept of nesting disgusted me. However, you said it best yourself: “This is clearly a case where your knowledge of what’s best should override using a tool.”

Nesting can be a big timesaver and can also present the visual hierarchy of code quite well, but it can also get out of hand quickly. The key is to apply your knowledge of CSS selectors to nesting so that you’re not getting too specific. Nesting shouldn’t result in an exact mapping of your HTML elements; it’s there to help you save time and to keep your code a bit DRYer than what you’d be able to do with bare CSS.

Also, regarding Jeff Croft’s comment on CSS gurus not understanding or needing programming logic, I call bollocks. CSS has existed without the aid of programming logic for years, but it also isn’t diluted by the introduction of such tools. I’ve used conditionals, for loops, and other iterative logic in projects before to great effect, and have saved a great deal of time doing so (mostly with very complex, UI-heavy web apps). The situations in which these tools prove their worth aren’t very common, but they really shine when used correctly.

Jon Faustman

November 7 2011 @ 04:35pm #

I’m starting to sound like a broken record because I’ve said this more than a few times, but I started with LESS because it was much closer to the CSS I was used to, and then switched to Sass when scss syntax came around. However, once I got more familiar with Sass, I realized that I was losing some of the benefits of the old Sass syntax (mainly succinctness) and now use it exclusively.

Starting with the command line was a bit of a hurdle, especially when I added Compass into the mix, but I’m glad I pushed through it because it greatly enhances the way I work.

I completely agree that nesting can quickly create less efficient CSS, but if you stay vigilant while developing, the power of nesting is irresistible.

My team sees the usefulness of Sass for larger projects, but their argument against it is adding another dependency (or rather multiple dependencies) to projects. Personally, the extra dependencies and dealing with command line is completely worth it.

Catherine Azzarello

November 7 2011 @ 05:02pm #

“To the typical CSS designer, the command line is a frightening place.” Sums it up PERFECTLY!

A couple years ago I heard about SASS and tried to use it. But that Ruby Gem thing chilled me to the bones. Terminal? Egads! Isn’t that fugly thing the easiest way to incapacitate my computer?

Tried again when LESS came out. Still confusing. Wasn’t feeling the javascript love.

And then there was Less.app. Sun shone and angels sang! But you’re right, the functions felt overkill and I did have some specificity problems. However, this year I started using P.erkins and was pleased. Best parts were buttons and gradients. I tweaked it to include my mixins and preferred grid system (1K) and then rolled it up w/HTML5 Boilerplate.

Just recently I was tying to determine if I’d start the next project with Foundation or Twitter Bootsrap. I really like Foundation’s logic (plus coming from a design firm, it ‘feels’ right), but Bootstrap includes some scripts that I need for this project. Bootstrap it is.

But…I’m not a fan of Boostrap’s grid system…too much verbiage, too difficult to set up for simple responsive layout. So I’ve commented out their grid styles and set up Semantic Grid for this (and likely others) project.

Here’s where Less.app really shines: if there’s an undefined style mixin or some problem, Less.app spits out an error report and will not compile the file until it’s fixed. This is a HUGE help for getting the hang of mixins and functions, not to mention better LESS writing all together. Not sure if using SASS or LESS.js would allow me to troubleshoot in the same manner.

Overall, I LOVE Less.app. My only problem is that after writing enough .radius(6); style rules, I sometimes forget how to write border-radius rules longhand. ;-)

Charles Roper

November 7 2011 @ 05:44pm #

@Catherine Azzarello

Using Sass on the command line certainly tells you when you have errors in your code. Scout also does the same (example
). Not sure about Compass.app. Has anyone used this?

Bryan

November 7 2011 @ 07:24pm #

Thanks for all the great comments about Less.app and CodeKit, guys! I’m glad you all find my apps useful.

Catherine Azzarello

November 7 2011 @ 10:31pm #

@Charles Thanks for the info. Think I’ll stay w/LESS for now…can’t learn too many things at once! ;-)

@Bryan Looking forward to CodeKit when I get a chance. Your site copy is a riot! :)

Steve Rydz

November 8 2011 @ 12:04am #

Great post Andy. This post gave me the final push I needed to check out LESS in more detail. I have been weighing up the benefits for sometime but it was hard to see past the technical side of things for a designer type like myself.

Already, after using it for a couple of hours this evening I can see the time and maintenance saving opportunities. Like yourself, I work in short, agile sprints so this will serve me and my clients well.

I’ve been working using the SIMPLESS app as I’m Windows based so I’m not benefiting from the minified aspect of this process but so far I’m impressed.

Peter Wilson

November 8 2011 @ 12:33am #

Generally, I avoid nesting in LESS too.

Where I do find it handy is with pseudo elements and pseudo classes. It improves scanability to have something like

a {
...
&:hover, &:focus {
...
}
&:active {
...
}
}

As for the sass/less debate, it’s meaningless. It’s far better an individual developer use what she is comfortable with rather than what the cool kids are using.

René Domingue

November 8 2011 @ 04:16pm #

I never used Sass or LESS before cause I’ve plenty of projects that are live. Use these helper is really pain in the ass when it’s on a remote server. You need to make your change and upload each time the css style generated. Or you need to put a JS that convert on the fly the SASS or LESS on the client-side. I really don’t love this method, client has enough stuff to load, I don’t want take more time to convert the CSS.
But I find a method to get this working really nice on a remote server. You can find the method here http://beta.rdsign.net/code/article_35. Since I use everytime SASS on my projects. It could be a really nice tool to help improve the rapidity of development.

René Domingue

November 8 2011 @ 04:20pm #

P.S. Sorry here is the link http://beta.rdsign.net/code/article_35.
P.S. Sorry again cause the article is in french, but it’s pretty straight forward and easily understandable.

Miller Medeiros

November 9 2011 @ 07:12am #

I just published a post explaining some problems related to CSS pre-processors. Cheers.

Gonzo

November 11 2011 @ 09:28am #

I got my degree in electronics before GUIs went mainstream. I learned to program in Pascal, BASIC, C and 68000 assembler. I also have qualifications in art and graphic communication.

I changed career in 2000 to be a digital designer and web designer.

For me, what’s the point of a GUI if you’re going to go back to the terminal and command-line? Do you still get a starting handle with a Ferrari?

A GUI isn’t to dumb-down the the process, it’s supposed to speed up the interaction. If you grew up with assembler language, you’ll probably be glad to see the back of ‘old-school’ command-line nostalgia which should have no place in a well developed framework. It’s not command-line fear, it’s developer elitism :)

Charles Roper

November 11 2011 @ 03:06pm #

I followed a similar path to you Gonzo. I grew up with BASIC and Z80 assembler (although I never really got on with assembly language), then moved to Pascal and C before switching to graphic design then later to web design. I now straddle the divide as an informatician. So I’ve used boths GUIs and CLIs a lot over the years. The thing is, a GUI isn’t inherently better than a CLI, as you seem to be saying. A GUI does (or should) make interaction easier and more intuitive, and it isn’t necessarily a ‘dumbing-down’ exercise, but a good GUI *is* something that takes time, effort and skill to do well. There is also the overhead of extra computing resources required. So many open source projects start with a CLI and not a GUI. Most *nix sysadmins live on the command line. The speed with which programmers can crank out CLI programs and iterate on them means that we have a far richer computing environment. We can interact with and control mutliple remote servers from the command line. Github can deploy a whole new build by issuing one command. The list can go on and on. Not only is proficiency on the command line useful, it can be fun in the same way coding your HTML and CSS by hand in a text editor can be fun. There was a good article recently written by Luke Wroblewski about how they build Bagcheck as a CLI app first, then progressively enhance. Have a read, it makes a lot of sense. In many ways, it’s the ‘webapp’ equivalent of the Content First ethos.

So to suggest that the command line is an anachonistic throwback to a forgotten ago of computing being clung onto by an elitist bunch of neck bearded uber-nerds is nonsense. Boths CLIs and GUIs have their place - they each have strengths and weaknesses. The real point is, if you’re a web designer or developer and you like to play with the latest tools and technologies, it’s worth rolling up your sleeves and getting comfortable with the command line because that’s where most of the innovation is happening. You can wait for GUIs to be eventually be produced for the more popular stuff (as has happened with Git, Sass, Less and so on), but if you want to stay on or ahead of the curve, get learning. It’s not even that hard. It’s not like learning an actual programming language or even HTML/CSS which can take years to master. No, learning the command line takes days and can reap fantastically fun and useful rewards. I recommend it to everyone with an interest in web development, just as I recommend learning to hand-code HTML/CSS.

TJ

November 12 2011 @ 01:31am #

LESS overs almost nothing over regular CSS, so I definitely agree with you there, no point wasting time with that, SASS on the other hand is much nicer

Jeff Croft

November 12 2011 @ 08:49pm #

For the record, I too, eventually came around to using a CSS preprocessor. I prefer SASS, but that’s mostly just because it was the first one I used (and I like the optional whitespace-sensitive syntax). My impression is that SASS and Less are pretty much equals at this point — so use whichever one feels good to you. But don’t write them off. They really do serve a great purpose, and once you get in the habit of using one, it’s really tough to go back to plain-jane CSS.

Petr van Blokland

November 13 2011 @ 12:58pm #

It might improve the discussion if requirements, tools and solutions get better defined. The overall problem for file formats as HTML and CSS is that they were never made for the level of information storage that we need today. Actually, they were mainly made for efficient communication between devices, which shows in the use of short abstract codes (<a>) and the lack of loops, conditionals, subroutines and inheritance (which is different from cascading).

As with the early days of Postscript, the initial absence of code generating applications forced users to “program” directly in the syntax and structure of the communication language.

That is a drag for at least 6 reasons:

1. The lack of procedural structure creates long linear repeating sequences, which are hard to maintain, especially if they are somehow related by rules and algorithms. That is not something an author ought to be doing manually.

2. The aim for efficient transmission reduces human readability of the data. Making codes as short as possible (no indents, short identifiers, cascading overlap, short comments) is in conflict with the requirements of data storage (adequate description of the function of the code, versioning, long telling identifiers, conditionals, abstract XML tagging for more structure than what is needed just for low level layout coding).

3. The legacy of storing overlapping information in three different formats (HTML, CSS and Javascript), all mixed in one document requires a lot of human understanding. The separating makes it is impossible to answer questions like “Did I describe the CSS code for all the classes used in this HTML document?” The manual debugging is not only a slow process, it also requires much knowledge and skills and it needs to be done ground-up again for every project.

4. Solutions to solve the ongoing incompatibility between versions and browsers, e.g. CSS prefixes ( -webkit- ) may work well on the level of browser interpretation, also they make the code even more unreadable and harder to maintain. It is not a problem if the syntax would be used entirely for communication between devices, but if temporary data-structures are used for storage they will exist long after the time they got obsolete. The validity of the final CSS output syntax for a given usage and given browser version should never be the responsibility of the design/author of the data.

5. Storing the knowledge about the structure and representation of information in a too low level syntax, prevents the use of that knowledge in other circumstances. Stored HTML and CSS data cannot be used to create similar documents in PDF, Office, future browsers, SVG, pixel images and InDesign input.

6. For a publisher or corporation, that handles multiple brands of publications, where part of the design and content is shared, the use of single CSS and template files multiplies the amount of redundant information to be maintained.

The development of tools like LESS, SASS and dedicated CSS editors shows the need for higher abstraction of data storage. However, almost without exceptions, these approaches start on the wrong end, all trying to swim upstream. The extreme usefulness of a simple @media conditional shows how bare the tools are. And thus how far away we still are from real intelligent publication systems. A CSS macro language will never solve the issues defined above. There is just not enough information available at the bottom. It will never be possible to make references from CSS to the Javascript using it, or to make CSS code appear, when the related tags are used in HTML. (A solution to these problems goes way beyond the discussion wether or not the interface to SASS should have a GUI or command line interface).

With hind sight knowledge the development of the web data syntax should have taken a different route. But reality dictates that we are stuck with this legacy, at least for a very very long time. So how to proceed? Development on the other side of the spectrum (Adobe trying to convert print tools into web tools) also does not promise to come with a solution soon that fits the requirements of “slightly above average”.

The solution is in making a drastic separation between data and tools and between storage and communication.
With the current frequency of changes on the side of browsers, the appropriate code should be made automatic, not manual. Instead of updating the CSS of a range of websites, one only should be updating the tool that generates the CSS. A designer should be able to use boxshadow=“0px 0px 7px rgba(0,0,0,.1)” without the worries to expand to the most recent prefixes.

The answer to all this is to define a high level document descriptor file – likely to be XML syntax – to describe every aspect of selection, ordering, formatting, representation and interaction on an abstract level. The description includes the behavior of different skins, different types of layouts and all meta information about the (type of) publication. All without knowing the output device or final output format. The syntax and structure of the descriptor file can be checked and modified and converted by existing XML functions such as XML-Schema, XSL and various XML editors. Converting the descriptor file to specific usage is just a matter of using the right engine. These are hard to create in the beginning, but they only have to be development once. Changes in the requirements of the output format only needs to be adapted to the tool, not to all the websites. The same descriptor can be used to generate the dedicated code for traditional sites, for responsive with fixed column width, responsive with liquid columns, but also to Wordpress theme files, PHP format and even rendering to PNG, SVG and the creation of PDF documents. All by using the relevant engine. Since all information is available in a single source, engines know the relations between the elements of the output files, so they can check and optimise.

These engines are hard to develop, but they are highly reusable, have single point of knowledge and they can be very specialized. Using object based languages such as C#, Java, Ruby and Python allows the development of reliable fast engines that take standardized document descriptors and convert it to all files needed for a specific CMS and device. There are many standard libraries (XML parsers, image renderers, etc.) available that can help to develop these engines. If you cannot do it yourself, then there is even more reason to join forces and let others make tools that really solve the problem, instead of painstakingly write the same CSS problems forever without the proper tools to do so. We do for some years now and I never want to write a single line of CSS again. Think of it.

(pardon my non-native english)

Alan

November 13 2011 @ 02:28pm #

Excellent article, and comments.

BTW, “be loathed”. Who would loathe you? ;) It should read “be loathe”.

chris

November 13 2011 @ 06:59pm #

a good read!
i’ve choosen sass, because it looked to me more supported with a bigger community and more future save. but thats jut my personal impression.
i startet to use is as i discovered the compass app: http://compass.handlino.com
this tool takes care of all the conversion-stuff without terminals, and it even runs from
an usb-stick everywhere, which is verry important for my daily life.

UpWorks

November 14 2011 @ 05:30pm #

A little late to the party but thanks for a great article and comments!

Ronald Fung

November 15 2011 @ 05:35am #

I couldn’t agree more with the use of LESS. Ever since I started getting proficient with CSS, I started asking myself the question: Why is there a desperate lack of structure and organization to CSS? In a large project, CSS files can go up to thousands of lines (I don’t like writing my CSS in-line, it’s both cluttered, and unreadable to human eyes), how are we suppose to extract anything useful or meaningful from this monstrosity.

Then, one day, I came across LESS. Quoting Guy Kawasaki, “angels started singing”! At the time, I didn’t know about SASS (I did come across it later on and had to work with it for a short while. It didn’t rock my boat, since setting up cost me almost an hour). What I love about LESS was the simplicity and easiness in adopting it in my project, drop a less.js in your template, and you’re good to go (note: only use the preprocessor in dev mode, you’d want to compile for sure for your production.)

Now my CSS are nicely structured and organized per sections (menus, toolbars, forms), and pages (home page, sign in page, everything else), and I am reusing by using mixins (see Paul Irish’s http://css3please.com). Having variables, even magic numbers in my css started to make sense (eg. 934px because i have a 12px padding and 1px borders on both sides).

I hope you enjoyed using LESS as much as I do. It really is a great development tool.

Gaurav Mishra

November 16 2011 @ 06:35am #

Use which ever technology Sass, Less or CSS
But no one escape from keeping the code minimum
and add every push to maximizing the code re-usability.

Lukáš Pečinka

November 16 2011 @ 10:32am #

I like your .font-size mixin but it seems the following line is not correct:

font-size: ~”@rem”;

it just prints out ‘font-size:@rem’. It should be:

font-size: ~”@{rem}rem”;

Also for people that set their base font size to 100% (as opposed to 62.5%), it’s really easy to adjust the mixin:

.font-size(@font-size: 16) {
@rem: (@font-size / 16);
font-size: @font-size * 1px;
font-size: ~”@{rem}rem”;
}

Tom

November 16 2011 @ 04:09pm #

hi, I’m a bit at loss regarding the colour-thingies in Less… you wrote:

@col : #468DB6; // Base colour
@comp : spin(@col, 180); // Complementary colour

actually, what happens in my testcase, the colour is not rotated BY 180°, but the “hue” value is set TO 180° - which results not in the complementary colour, but somewhere near my basecolor (which as a hue vlaue of 250°). The same applies to the other thingies like desaturate() or lighten() - it’s always set to the value, not modified by the value. for example, I have a basecolour which has a “B” value (in HSB mode in Photoshop) of around 39%. what I expected to happen with lighten(@basecol,80%) is, that I’ll end up with a colour thats 80% lighter than my base, but what I get is a colur with “80%” as new value in “B”. 38%—> 80% is not “80% lighter” (that’ll be around 68% as new value).
So either I don’t get this whole HSB/L colourspace thing (which is more than likely) or I’m doing it totally wrong (which is more than likely) or the description in Less is wrong (which is not as likely?)
anyway, any help is greatly appreciated,
tom

Tom

November 16 2011 @ 04:39pm #

Hi again,
I cleaned up my test case and I think the problems are not as I assumed. the spin() function really does rotate the colour, but it’ working on the “hue” value only. So if you take a base like #FF0000, and spin(base,180) you’ll get #00FFFF, which is what one would expect. If you have a base like #4D4962 - that’s 250°,26%,38% in HSB, and now spin(base,180); you’ll get #5E6249, which is 70°,26%,38% in HSB. if you add 180 to 250 you have 430 and that’s 70 more than 360 - so mathematically everything is correct. But since the other two values are untouched, you will not end up with the “right” (as in visually) complementary colour which should be more like #b2b69d (according to photoshop) which is 70°,14%,41% in HSB.

Tom

November 16 2011 @ 05:04pm #

ok, part three of my colour-spam…

here’s what happens with the lighten() function: I tested 30%, 50% and 80%, starting at my basecolour of #4D4962.
that gives me:
30% #9994b0;
50%: #d1cfdb;
80%: #ffffff;
and that 80% value is the one that confused me, how can 80% of a basecolour be white?
looking at the HSB values:
100%: 251°/26%/38%
30%: 251°/16%/69%
50%: 250°/5%/86%
it seems to me that the percentage value of “B” gets added to the value that’s already in the basecolour, and if the result is > 100, *bam, you’ll get white.

Nedra Burkhardt

November 17 2011 @ 05:41pm #

Hi mate! I fully agree with your opinion. I’ve just added it to bookmarks.

JODYJoyner20

November 19 2011 @ 10:28am #

If you are in the corner and have got no money to move out from that, you would require to receive the business loans. Just because it would aid you definitely. I get student loan every single year and feel myself OK because of this.

Commenting is not available in this channel entry.

LESS

Leave your comment

UpWorks

Hardboiled Web Design by Andy Clarke