Tips for using and debugging of Less CSS code

Just think of it: normally I find the right line of code from within the browser in an instance by opening Firebug (or something similar) and look up the line number and CSS file that holds the style code that I would like to edit. Another option is to just copy the selector (if your developer tools hasn’t rewritten that) and search it using Ctrl+F in my editor.

But with Less the CSS code gets parsed, combined and most likely minified. With Less or Sass you cannot trace back styling via your developer tools in a simple manner.

At the moment I’m building a HTML/CSS/JavaScript framework based on Less and ASP.NET. Because that framework will get a solid code convention I’m convinced that I can keep the issue of not being able to find the right CSS code to a minimum. But I’m pessimistic about the solidness of Less-code that is written uniquely for each website. Such code does not get the same tender love and care as the reusable code of a framework. Furthermore: it is often bound to deadlines and budgets which may lead to sloppy code.

In worst case scenarios the Less code becomes a black box that magically generates styling but cannot be edited because it hides its inner workings. The only way to edit the style is to add an exception at the end of the Less file and maybe adding an !important.

In short: the ability trace back code styling might get close to null.

My personal guidelines for Less

Make your styling findable

Use a code convention which enables you to trace back the original Less code. As an example: I’m creating a lot of components for a framework. Each component is a block of code written as a nested rule like this:

/**
 * Root styling for menu
 */
.gp_menu {
	ul {
		background: @gp_colorLow;
	}

	> ul > li > a {
		display: inline-block;
	}
}

In my personal code convention I committed myself to make only one level in a nested rules block and to use a unique root selector. So if I see in Firebug a selector like .gp_menu > ul > li > a, I can search in my project for .gp_menu { to get to the right nested rules block. Then I can use > ul > li > a to finally get to the right point in the code to edit.

Now the code you see up there is just the base styling. It needs more styling to make it a real menu. In my framework there are many components that share the same basic styling. Let’s add some code to create a horizontal and a vertical menu:

/**
 * Horizontal menu
 */
.gp_menu.gp_menu_typeHorizontal {
	min-height: 0;

	&:after {
		.clear;
	}

	/* ... lots of more styling */
}

/**
 * Verical menu
 */
.gp_menu.gp_menu_typeVertical {
	li.gp_active > ul {
		display: block;
	}

	/* ... lots of more styling */
}

Now if I open up my Firebug and find a selector like .gp_menu.gp_menu_typeVertical li li, I know I have to search for .gp_menu.gp_menu_typeVertical {. This way code conventions helps me to find the right Less code.

Be cautious using Less in quick ‘n dirty projects

Deadline pressure can easily make a person write bad, unstructured code. With Less it gets even worse: bad, unstructured code and really hard to debug. You should think twice about letting that intern build the base styling of a website, but think three times if you let that intern write Less code for a website. You will be the one who has to debug it at the end of the project!

Better like your Less parser, it might be your only one

Do you like your Less parser? That’s good, because your Less code might not get parsed by other Less libraries. I’ve written my Less code with .less for ASP.NET and tried to parse my code with SimpleLess. It failed to compile the whole bunch without a proper error message.

Part of the problem is that a bug in CSS (or differences in interpretation for that matter) are ignored in browsers, but Less parsers will throw a big fat exception. Exceptions can be a good thing but not if it differs between parsers. Maybe Less has to be adopted as a standard by the W3C?

Having a solid standard would be a good thing since Google just presented their own take on Less CSS with Closure Stylesheets. They already bended the informal JSDoc spec towards their own standards with previous Closure releases.

Update: LessCSS LinkedIn group

I created a LinkedIn group for LessCSS.