Last week, I shared my thoughts on Going Above and Beyond The WordPress Coding Standards. In one of the comments, K. Adam White asked how I manage my LESS files and my JavaScript files.

Though I manage them similarly, I think that each type of file is deserving of its own post, so I wanted to start by sharing how I’ve been using LESS in WordPress.

Before I share exactly how I structure my LESS files, it’s worth noting that I use CodeKit For WordPress┬áto manage my LESS and JavaScripts assets.

I mention this because there’s also a JavaScript parser, as well. Rather than including that particular JavaScript file, I have CodeKit compile my LESS files, and then enqueue the resulting CSS using the WordPress API.

1. Directory Structure

Using LESS in WordPress: Directory StructureFor the most part, all of my CodeKit-based WordPress projects are organized the same way. That is, I have a specific directory structure that I use to organize my files.

When it comes to using LESS in WordPress, I use the following convention:

  • In the root of the theme or plugin directory, there is a css directory. This directory is where all CSS files live – including my compiled LESS files.
  • In the css directory, I maintain a subdirectory named less where I keep all of my LESS-based CSS.
  • With the exception of certain circumstances, there are usually two LESS files: theme and admin: theme.less is for the public-facing aspects of the site, admin.less is for the dashboard.

When CodeKit compiles the LESS files, I have it configured to write out the files into the root of the CSS directory. This way, when I deploy a site, I can exclude the less directory from the deployment keeping only the actual CSS files needed for the project.

2. Organization of Styles

Using LESS in WordPress - Organizing Styles

For the most part, I don’t keep a variety of LESS files. Instead, I like to keep a single, well-organized file. As such, I usually follow these conventions when writing my LESS files:

  • Variable definitions and imports always reside at the top of the file
  • Element-specific code resides in the middle of the file (I’ll touch on this more momentarily).
  • Mixins, Namespaces, and other function-like behavior stays at the bottom of the file

For the element-specific code, I usually break this up based on how the markup is structured. For example, say that there’s an overall container that wraps a header that has a menu, content-wrapped which wraps content and sidebar, and a footer.

Thanks to nested rules, the corresponding code would be organized something like this:

/*--------------------------------------------------------------*
 * Variables
 *--------------------------------------------------------------*/

@black:	#000;
@white:	#fff;

/*--------------------------------------------------------------*
 * Header
 *--------------------------------------------------------------*/

#header {

	#menu {
	}

}

/*--------------------------------------------------------------*
 * Content Wrapper
 *--------------------------------------------------------------*/

#content-wrapper {

	#content {
	}

	#sidebar {
	}

}

/*--------------------------------------------------------------*
 * Footer
 *--------------------------------------------------------------*/

#footer {

	#credit {
	}

	#copyright {
	}

}

/*--------------------------------------------------------------*
 * Mixins
 *--------------------------------------------------------------*/

.border-bottom() {
}

Obviously, this is a very simple example but the point still remains: variables at the top, elements in the middle, function-like code at the bottom.

3. Ending Code Comments

As much as I love nested rules and being able to structure my styles similar to my markup, the file can still get a bit lengthy. As such, I like to also add terminating comments to make sure that I know which brace is closing which block.

Here’s an example from a current project:

#header {

	#menu {

		background:	@blue;
		color: 		@white;

		.nav {

			.menu-item {

				a {
					color:			@white;
					text-shadow:	none;
				} // a

			} // .menu-item

			.open {

				a {
					color: @blue;
				} // a

			} // .open

			.dropdown {

				.dropdown-menu {

					.menu-item {

						a {

							color: @blue;

							&:hover {
								background: @gray;
							} // :hover

						} // a

					} // .menu-item

				} // .dropdown-menu

			} // .dropdown

		} // .nav

	} // #menu

} // #header

I do this just as I do with functions for the same reasons: The IDE will highlight the matched brace, but it’s not always in the viewport. Being able to glance at the code makes it much easier to keep working while keeping track of where I am in the styles in comparison to the markup.

Those are the three big things that I do to organize my LESS files. I’ll cover how I manage JavaScript in a future post, but for those of you who are using LESS (or even Sass), I’m interested to know how you guys organize and maintain your files, as well – I’m always looking to pick up something useful!