What is LESS?

LESS — Leaner CSS — is, in the authors’ own words, a “new version of CSS” (better yet, of writing CSS), that is then compiled into “traditional” CSS using the LESS compiler.

There are 4 main things you can do with LESS that you can’t with normal CSS:

1. Variables

You can define a variable, such as “@text-color”, and use it throughout your stylesheet. If the colour of your text changes, you only need to change it once in your CSS — where the variable is initially defined.

2. Nested selectors

With nested selectors, instead of doing this and repeating yourself:

aside h1 { font-size: 24px; }
aside h2 { font-size: 18px; }

You can have:

aside {
	h1 { font-size: 24px; }
	h2 { font-size: 18px; }
}

3. Operations

You can add, subtract, divide and multiply using operations. Here’s a quick example:

@wrappers: 600px;

aside {
    width: @wrappers / 2;
}

This is definitely not the best example, but it should be enough for you to get the point.

4. Mixins

Mixins work a lot like variables, but you can specify a whole class in one. For example:

.b-radius {
	-moz-border-radius: 5px;
	-webkit-border-radius: 5px;
	border-radius: 5px;
}

.box {
	.b-radius;
}

From these examples, I suppose you can say that LESS is actually more. (I’m sorry, I couldn’t help myself.)

This is not a “how to” guide

The official LESS documentation is very clear on how to install it. I have to admit I usually stop reading instructions whenever “Terminal” is mentioned (and I know more people do), but I guess most CSS authors will be OK with it — if not, ask for help to your nearest web dev (or email me and I’ll give you the phone number of one).

After it’s installed, you’ll have two files: the .less file — this is the file you’ll be working with — and the compiled .css file.

There’s also LESS app, that makes it easier to use LESS. And I suppose that some CMS and servers let you use LESS directly, but the point of this article is not to teach anyone how to install it — it’s to go through its good and bad points.

On to the important bit…

How LESS can make your life easier

This is a list of things that, in my opinion, make LESS worthwhile and can really simplify your CSS. These are the things that I usually miss the most when I’m not working on LESS files.

1. Variables

Surely when you are writing your CSS there are colours, measurements, etc. that you keep using over and over. For example, let’s say your brand colour is jade (very fashionable for Spring/Summer 2010). You may use it on various elements in your design, for example, the main text:

body {
    …
    color: #77b59d;
    …
}

Or the borders of your posts:

article {
    …
    border-bottom: 1px solid #77b59d;
    …
}

Or as the background of your footer:

footer {
    …
    background-color: #77b59d;
    …
}

If someone has to edit the CSS file and doesn’t know exactly which colour he or she is supposed to be using — it may even be you a few months later —, what happens is that either you’ll spend some time scanning through the document until you find the colour, you’ll use Firebug or, if you like to complicate things, use xScope or take a screenshot and use Photoshop to detect the colour.

This is silly. You’ll end up with many similar colours instead of just one. (As a note, Dreamweaver lists all the colours that a site is using — you’d be surprised at how inconsistent some CSS authors can be when applying colour.)

Another thing that may happen is when you actually want to change this colour throughout your stylesheet: you’ll have to edit every instance of it — that’s painful.

With a variable, you can have this:

@main-color: #77b59d;

body {
    …
    color: @main-color;
    …
}

article {
    …
    border-bottom: 1px solid @main-color;
    …
}

footer {
    …
    background-color: @main-color;
    …
}

Beware though: you can easily go overboard with variables. I have to confess I was inebriated in the beginning by the thought of never having to declare a colour, a padding value, etc. again, and started adding too many variables to my LESS files. It gets messy and complicated quickly. You’ll have to find a balance.

2. Accessors

If you only need to access something once, you probably don’t need a variable. If you’re pretty sure that that thing you need to access is, and will always be, directly linked to whichever thing you’re linking it to, you can use an accessor.

Let’s say you have a block with a heading and some text. You want the border of that box to always be the same colour as the heading. You can have this:

#sales {
    border-color: #ae7b2a;
}

#sales h2 {
    color: #sales['border-color'];
}

Using accessors may be going a step too far in some cases, but in other cases it makes a lot of sense — I think they’re quite useful.

3. Mixins

One example: gradients. Let’s face it, they are an absolute pain to write. Take a look at how LESS makes it easier for you:

The mixin:

.grad-linear (@start:"", @end:"") {
    background: -webkit-gradient(linear, left top, left bottom, from(@start), to(@end));
    background: -moz-linear-gradient(-90deg,@start,@end);
}

Using the mixin in your .less file:

nav {
	.grad-linear(#b3cdcc,#718a89);
}

What your compiled .css file will show:

nav {
	background: -webkit-gradient(linear, left top, left bottom, from(#b3cdcc), to(#718a89));
	background: -moz-linear-gradient(-90deg, #b3cdcc, #718a89);
}

Mixins are great for properties that still require that we add some vendor-specific code (like border-radius) or for the latest CSS3 gradients, transitions, etc.

I have to say mixins, especially when used for gradients and border-radius, are my favourite part of LESS.

4. C-style comments

Some people prefer these to typical CSS inline comments. I’m OK with either, but if you’re using LESS, you can have either this:

/* A normal CSS comment */

Or this:

// A C-style CSS comment

5. Nesting (in some cases)

Nesting is one of those things that makes you think LESS is amazing at first. Then you start using LESS and start nesting selectors, and change your mind.

The rare instance where I think nesting is useful is with link states in simple selectors. In LESS you can have this:

a {
    :link, :visited { text-decoration:none; color:#edd273; font-weight:bold; }
    :hover, :active, :focus { color:#edd273; border-bottom:1px solid #edd273; }
}

And the output will be this:

a:link {
  text-decoration: none;
  color: #edd273;
  font-weight: bold;
}
a:visited {
  text-decoration: none;
  color: #edd273;
  font-weight: bold;
}
a:hover {
  color: #edd273;
  border-bottom: 1px solid #edd273;
}
a:active {
  color: #edd273;
  border-bottom: 1px solid #edd273;
}
a:focus {
  color: #edd273;
  border-bottom: 1px solid #edd273;
}

There’s a lot of repetition in here, I know (I’ll mention that on the next section), but it’s nice nonetheless.

How LESS can easily become a nightmare

This is a list of things that I would either avoid doing in LESS or that just don’t work the way you’d expect them to (so, annoyances).

1. Nesting (in most cases)

As I just mentioned in the previous section, nesting looks nice at first, but it doesn’t work flawlessly.

One of the things that I’ve noticed for example, is that, even though you can have this:

nav {
  ul {
    li a {
      :link { color: red; }
    }
  }
}

This won’t work (notice that now I’m using a direct child selector instead):

nav {
  ul {
    li > a {
      :link { color: red; }
    }
  }
}

For this last bit of CSS to work, you’ll have to do it like this (notice the extra “&”):

nav {
  ul {
    li > a {
      &:link { color: red; }
    }
  }
}

This not a problem with LESS, I guess it’s just not a very intuitive way of doing it just for using a different type of selector.

The main thing, however, that I think makes nesting a poor choice in most cases, is how it can make a mess out of specificity [here's a post I've written previously on specificity and other matters].

Your first instinct is to nest everything inside the main blocks, like aside, #sidebar, #news, etc. But then you realise you need to reutilise a piece of the CSS for another area on the site. You make another nested selector for that new block, because you don’t want to go over that first nested block of CSS that you created in the first place. You’ll be left out with numerous redundant selectors, with very long selectors (because you don’t notice this until the compiler phase), and with the need to create overly specific selectors to override your initial ones (that shouldn’t have been so specific to begin with).

Nesting selectors is one of those cases where the phrase “with great power comes great responsibility” makes a lot of sense. Use it wisely and carefully.

2. Changes made to the compiled file

This isn’t a problem with LESS per se, but rather with your working process.

Even if you are the only person in charge of the CSS on a given project, it’s possible that someday you will leave, or hand the project over to someone else, so it’s a good thing to make sure that no-one is going to edit the compiled .css file directly instead of the .less one.

If this happens, and then after a while someone does use the .less file, when it compiles, it will override the changes made to the .css file. Then you’ll have to go back and fix it.

This is just a general problem with people: if there’s a chance that we can make a mistake, we will make it.

3. Formatting

The .css file that results from the compiler gives you back your CSS with no comments and single-line declarations (that have more than one property). It would be useful if you could have some control over this. For example, you may want to minify the CSS (although you could argue that this should be a completely separate step), keep comments in, have multi-line CSS, group selectors, etc.

I’m not entirely sure if this has been resolved, so if someone knows better, do let me know.

4. Using Firebug

I can’t work without Firebug, and one of the best things about it is knowing exactly which line you’re looking at. If you’re using LESS, that’s broken: Firebug shows you the line of the compiled .css file, not the original .less file you’re editing, which is basically useless.

Conclusion

I love LESS and I think it’s a pleasure to use, until you start trying to be too clever and things start getting messy. My advice is to use it with care, take advantage of its niceties but don’t go overboard.

I know there are lot more problems (and probably good things too) that I haven’t referred. These are the ones that I’ve personally came across with; I try not to use LESS on larger projects and I usually don’t use @import on my stylesheets (especially smaller projects) — which I know can cause some problems.

I’d love to know what your thoughts are on this: have you used it? Why, or why not? Which problems have you encountered? Do you find it helpful or just plain silly?

An overview

Although CSS3’s use has been increasing among web designers, browser support for some of its features is still inexistent.

Lately, I’ve been using Modernizr more and more to cater for those browsers that don’t support specific CSS3 properties—for example, on my site—, and it makes the development much easier because I know I’m providing these lesser browsers with an alternative experience, rather than just ignoring them.

Bear in mind (and this is even splashed on Modernizr’s front page), that Modernizr doesn’t actually magically enable these properties for browsers that don’t support them. It just tells the page whether that feature is supported on the browser the visitor is using or not.

How it works

To install Modernizr, download the file from this page. Then, on your site’s head tag, add a link to the file. For example:

<script src="js/modernizr-1.0.min.js"></script>

The second step is to include on your html tag a class of “no-js”:

<html class="no-js">

Why add this tag?
Because that will be the default state of the page. If JavaScript (js) isn’t on, then Modernizr won’t work at all (and probably other features of your site won’t work either…), so it’s good that we have a fallback for that case.

If JavaScript is indeed enabled, once that page is loaded on the browser, that class will be replaced dynamically and it may look something like this:

<html class="js canvas canvastext geolocation rgba hsla no-multiplebgs borderimage borderradius boxshadow opacity no-cssanimations csscolumns no-cssgradients no-cssreflections csstransforms no-csstransforms3d no-csstransitions  video audio cufon-active fontface cufon-ready">

What does this mean? 
Let’s take a look, shall we?

In this case, I opened the page on Firefox 3.5. This browser (sadly) doesn’t support multiple backgrounds, CSS gradients or CSS transforms, therefore, Modernizr outputs “no-multipebgs“, “no-cssgradients” and “no-csstransforms“. On the other hand, it does support canvas and border-radius, which explains “canvas” and “borderradius“. Etc.

How to use this (precious) information?

So what can you actually do with this? How does that help you in any way?, you might ask.

Let’s look at an example:

Multiple backgrounds

Your site’s background has been carefully built and you’re using the multiple background technique to make it simpler (and faster!) to code. Your CSS may look like this:

#nice {
	background: url(background-one.png) top left repeat-x,
	url(background-two.png) bottom left repeat-x;
}

And a nice browser will render this:

Using Modernizr, your CSS will look instead like this:

#nice {
	background: url(background-one.png) top left repeat-x;
}
.multiplebgs #nice {
	background: url(background-one.png) top left repeat-x,
	url(background-two.png) bottom left repeat-x;
}

This is what your visitors will get, depending on which browser they have:

This is a very simplified use of Modernizr, but hopefully it’s enough to show you what you can do with it.

HTML5

Modernizr also allows you to use the new HTML5 elements—header, hgroup, section, footer, video, etc.—and style them.

This doesn’t mean that some of these elements will start working on Internet Explorer, but that you can style them and that IE will understand them and not ignore them.

JavaScript

You can also detect features using Modernizr in your JavaScript, using this syntax:

if (Modernizr.geolocation) {
}

Conclusion

I hope that I managed to explain the usefulness of Modernizr. While we can’t rely on the fact that browsers support the full spectrum of features we want to use, this is the best tool out there to provide for both worlds.

Do you use Modernizr too? How? If not, how do you deal with some browsers not supporting some features (assuming you are using the latest CSS3 techniques)?

Attention, rant alert!

First things first: not everybody that uses Dreamweaver is using it in the Design mode, or even Split mode. Or uses the automatic CSS creator/editor tool.

My intentions with this post are not to convince anyone to move from whatever tool they’re using to Dreamweaver—just to make people understand that Dreamweaver is not that little evil tool everyone seems to think it is—a tool for people who can’t code.

One of the reasons I wanted to get a Mac was because then I would be able to use Coda. It looked so clean, intuitive and without all the clutter that Dreamweaver brings with it! Then I finally got my hands on to a Mac, and actually tried Coda: it didn’t last a day.

I’d like to be able to use a cooler or prettier tool, and, believe me when I say that I’ve tried a lot of them: Coda, Espresso, BBedit, Notepad, etc. I end up frustrated because simple things I’d like them to accomplish just aren’t there or, when they are, they’re not clear.

But don’t get me wrong: Dreamweaver is far from being perfect! It’s just that I’m more prepared to miss out on the great new features that keep popping from the new apps, than from the simple ones that Dreamweaver provides me with and that help me code faster.

I’m sorry I won’t be adding any screenshots to this post, I just have to let this out of my system as quickly as I can. :)

The details that matter to me

This list focuses on the way I use Dreamweaver, and that is mainly to code HTML and CSS. I’m aware that I don’t use it to its full potential, so this list could be so much longer, right?

So why do I like it so much then?

• It adds links to the external files your HTML is linking to at the top
• The list of colours, assets, links used in a Site
• It doesn’t close HTML tags as soon as I open then
• It closes HTML tags if I type “</“
• You get a list of all available CSS classes and ids when you're typing "class=" or "id="
• It auto-completes the properties in CSS files (yes, all the others probably do that as well)
• You can add strong, em, or headings, for example, with just Cmd+B, Cmd+I, or Cmd+1
• If you type "&" in your HTML code, you get a list of glyphs available
• It doesn't add annoying project files to my folders
• Search and replace across an entire site
• The inbuilt FTP: it's not great, but it's OK for quick uploads
• I can use the tab key to indent several lines of code without the need of a plug-in
• Update: If you set up a Site, and then change the name of a file (html, image file, etc.), it updates the links to that file within the Site
• Update: When inserting an img tag, after inserting the source file code, Dreamweaver adds the correct height and width automatically when you type in height and width

People keep trying to convince me to move from Dreamweaver (and sometimes I try to convince myself), but save your words if none of the above mentioned features is present in the tool you’re about to recommend.

I’d also like to add that I don't use Dreamweaver's live preview—I never got used to it because it used to suck (I've heard it's a lot better now though), so I use a combination of Firefox and Firebug to do the live editing.

The details that I don’t love, but that I can live with (or without)

• The price tag. At almost £400 (or $399), it’s quite expensive and sometimes prohibitive
• It can be slow
• It’s not as pretty
• It doesn’t know which properties have already been used for a particular tag
• Search and replace could be nicer (like Espresso’s)
• I’d like to have a more visual navigator (like Espresso, for example), but it has one that serves its purpose well
• Spelling checker: if there is one, I don’t know where it is (Espresso has it)

Dreamweaver is sad

So please, next time you say mean things about Dreamweaver, think twice, look at how sad it is:

Photo by protographer23

What would you like to add? Are you a Dreamweaver hater? Do you secretly use it when no one is looking?
Let me know in the comments section!