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
For 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
cssdirectory. This directory is where all CSS files live – including my compiled LESS files. - In the
cssdirectory, I maintain a subdirectory namedlesswhere I keep all of my LESS-based CSS. - With the exception of certain circumstances, there are usually two LESS files:
themeandadmin:theme.lessis for the public-facing aspects of the site,admin.lessis 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
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!
You’re blog has become my favorite place for practical, easy to understand information on web development.
You’re my web dev hero.
Flattered. Thank you sir.
Good point on the mixins and namespaces. I have been putting them right after my variables, but I see how it makes more sense to put them at the bottom. Removes the need to scroll to view the styles. Good tip. Thanks Tom!
I’m not totally sold… I know LESS doesn’t require it, but I still feel more comfortable declaring functions before I try to use them.
I’ll actually admit that it’s a bit odd that I do this considering when I write JavaScript, I put all of my functions at the top of the file before actually writing code that uses them.
That said, I actually put helper functions at the bottom of the file whenever I’m working with classes or
function.php. Mentally, I guess I think of mixins as helpers, when in reality, they probably should be defined at the top of the file for the sake of consistency.Nice post, what’s with the over specific CSS though? Are there going to be more than one elements with the ID of #menu that you needed to nest it in another ID selector of #header?
My rule of thumb, never use IDs!
When it comes to writing SCSS or LESS, its easy to nest too deeply. Consider rewriting with less selectors and you’re code will be more modular and more light weight.
The “over specific CSS” was mainly for two reasons:
Interesting thought on ID’s, though. I use them sparingly, but I think it totally makes sense to use them when there is a unique element.
Thank you for posting this, Tom! I’ve stumbled across some of the same conventions, but I’d settled on a more multi-file strategy similar to the one Noel Tock describes in his post on using LESS with WordPress. I have found the modular approach particularly useful for maintaining common elements (such as helper classes or normalize.css) as external files that can be included with my project boilerplate. What do you see as the advantage of maintaining the code in a single file, rather than breaking things up?
I’ve used the modular approach in larger projects, but I don’t use them all of the time.
When I have third-party dependencies, like you mention with
normalize.css, I do use imports, but I don’t usually start off with breaking up my file.I think there’s a balance between having a single, lean LESS file and having too many specific files. Because of that, I don’t think there’s a one-size fits all solution – I see it more as a “what’s best for this project.”
I would suggest you to use Lessify WordPress Plugin as it works perfectly and i am quite using this all of my projects. Just download and install the plugin and it worked perfectly.
Not a bad idea – I think it’d definitely work well for some depending on how their development stack if setup. I’m personally a fan of using something on my local machine before pushing it to production, but – again – that’s just me :).
Guys check out this plugin. Works great with wordpress
http://wordpress.org/plugins/lessify-wp/