Having been initially enthused by the idea of LESS CSS, then horrified and totally against it, I now find myself using it for every site I build and enjoying it more and more. Even doing small amounts of work in plain CSS, such as a print stylesheet, feels awkward and clumsy in comparison.
Despite my acceptance, I still have cautionary advice to dispense regarding its use. Here then are some thoughts on how to organise your LESS files.
My general aim whenever I'm coding to to produce something that is clear and understandable, not only for others who may need to work on it after me, but for myself if I need to work on it six months later. The vehemence with which I have cursed sloppy front end developers is equalled only by the horror with which I have surveyed my own past work where I have not been successful at this aim.
The following are all ways that LESS files could be named and structured, along with some thoughts on each.
The not-getting-the-point-of-less way
First of all, you don't have to use multiple files at all. You could simply have a single LESS file that contains all of your site's CSS and then compile it again into a single file.
I hope that anyone who has any understanding of LESS doesn't do this, as it detracts from one of the main reasons to switch to it. Splitting thousands of lines of CSS out into multiple files aids clarity, understanding and future navigation and maintainance of your code. If you're still using a single LESS file for anything but the smallest of single page sites, you're doing it wrong.
The Bootstrap way
Bootstrap's LESS serves as a good starting point for this discussion. The LESS is grouped by element type and their own categories, for example:
- It's easy to find what you want to, because all the files are labelled simply.
- It's very easy to add another less file for some group of components you might have missed or not needed yet, simply by adding another file.
- One person's naming convention may not be another's. In bootstrap 2 I kept looking for icons in a file I assumed would be called icons.less, when the file I actually needed was sprites.less.
- This works well when there is no ambiguity - forms will always be called forms, but what does scaffolding.less contain? One developer might disagree with another over the content that file should have.
- Splitting everything out like this does mean a lot of files get created.
Most of the disadvantages here can be overcome by good documentation, which Bootstrap has.
Location of elements in the site/page
You could structure your LESS based on where it occurs in the page or where it occurs in the site, rather than by element type.
- It's reasonably clear where everything should go.
- Fewer LESS files are needed.
- Some of these files might get disproportionately large. Header and footer might be relatively small, but content could be pretty much all of your site.
- Ambiguity may be introduced once elements that could occur in multiple places are introduced.
- Variables and mixins don't go nicely into this naming structure, unless you start splitting them up, which may prove unwieldy.
I wouldn't recommend this approach. You'll find successive maintenance of files organised like this to be too annoying. I once worked on a site that used this structure..
That might look fine at first glance, but here's a question - where would you find the CSS for lists? Any structure where a developer ends up grepping through it most of the time is a bad structure.
What I (used to) use
This system borrows heavily from both of the above approaches and also from some other front end devs I've worked with over the years.
- The structure is set and will not change.
- Some people may not be comfortable with numbering files like this, but it only really causes a problem if you suddenly decide mid-way through a project that you really do want to put another file in between 4 and 5.
- Naming is still ambiguous, for example it's arguable sometimes whether styles belong in components or page.
- The base file can get pretty big, because it usually contains all the typography and form styles.
What I actually use now
Having come to the realisation that the system above worked for me but not anyone else, I've decided on a new approach. Like Bootstrap, I now use a separate LESS file for each element type (e.g. forms.less, lists.less) and have LESS files for a few obvious element types, e.g.
I also use a few 'page location' LESS files...
Also like Bootstrap, I use dedicated variables.less and mixins.less files. Responsive styles are compiled into a separate stylesheet (using the same variables and mixins files) so I can serve it up to older browsers if they can't handle the normal CSS. This involves a new responsive specific file where needed, for example forms.less and forms-responsive.less.
Essentially, my current approach is a combination of the best bits from the other approaches I've outlined above. You can see the full list of files here. This is a forked copy of a repo I built originally for work, which we now use as the starting point for all our projects.
Regardless of what approach you eventually decide upon, I would recommend the following.
- Put a comment at the top of each LESS file explaining what it contains.
- Build a complete styleguide for your LESS containing examples and code samples and include clear explanations of how to use your LESS.
- If you do something really clever and complicated within your LESS, explain it. Not everyone is a LESS syntax guru.