I’ve been working with LESS/SASS for about a year now and have learned quite a lot. I’ve struggle with compilers, changed languages, built several frameworks for faster development, transferred from one system to another, and so on. I’ve worked through bootstrap when it came out, took my notes, adjusted it for my needs and deployed it with my Tseczka Boot flavor of my Tseczka themes.

From my ventures, I’ve learned how to elegantly declare my properties, how to style my websites with organization, rigor, and speed. I’ve learned a few tricks as well.

Where To Start

Starting on a large project can be intimidating and can be difficult. You need to be versatile, you won’t know exactly how many stylesheets you’ll need, what may conflict, what to do with certain properties and so on. The goal is to recognize that if a stylesheet gets too complicated, you can break it up into manageable pieces.

Take WordPress development for instance. Yeah, yeah, I’ve heard it all, you don’t need anything fancy for it but with an increasingly larger use of WordPress as a CMS, you’re not dealing with the standard [header][content][sidebar][footer] scenario, you’re dealing with custom portfolio pages, slideshows, and unique pages meant for something particular to the industry the blog targets.

I break my development down with a simple skeleton that literally copy/paste from project to project. Think of it as my personal Bootstrap:

With this structure, I tackle the most mundane parts of WordPress development: the repeating start. Here’s what all those files do:

  • basics – basics sets up the typography, reset, and “top-level” element styles such as anchor tags, paragraphs and so on. This file is actually the second to be parsed because I do use a variables sheet.
  • bootup – this file imports all of its adjoining files in a specific order
  • colorschema – a variable stylesheet. In my newest projects, I renamed this files “vars” and it includes mixins. It’s the first file to get imported
  • construction  – contains layout framework, grids, and so on. Also contains media queries that work with the construction
  • extras – contains miscellaneous extras such as extra column grids, buttons, or specific CSS to the installation
  • footer – contains ONLY footer information. This makes the footer EXTREMELY modular. I can take this stylesheet and my footer code and place it on any site with minimal code changes
  • forms – basic form formatting
  • navigation – same thing as footer but with the header. Very modular
  • sidebar – self-explanatory
  • slider – includes basic styling for any slideshow I want to include.
  • wp – wordpress specific styles such as styles affecting .alignleft, .aligncenter and so on.

I start with this setup on every single one of my projects. I’ve created so many WP sites that this system was thoroughly tested for me and it works. If you look at the structure, you’ll realize that it is quite simple. If you ever need to change anything, you’ll know where to go. Need to change the font? Basics. Need to use a different grid framework? Construction. Want to include styles for a new button? Extras. How about the nav? Navigation.

Break it down (OOP)

So your first steps will be analyzing your sites needs and creating basics stylesheets you’ll grow out of. It’s important to follow some kind of convention with this. I am working on a huge project right now and have spent a great deal of time to figure out how to style it and what conventions to use. Here’s a good breakdown:

  • master CSS– this stylesheet will contain all of the basics of your project included everywhere. It will broken down like so
    • vars/mixins
    • reset
    • typography
    • grid framework
    • navigation
    • footer
    • forms
    • project specific stuff broken down further like so:
      • profiles
      • commenting
      • so on
    • common UI elements (buttons, etc.)
  • main section CSS – has the main page. Contains ONLY specific stuff to that page
    • page specific overrides to the master overrides.css
    • new styling for non-common UI such as a portfolio piece
  • 2nd section
  • 3rd section
  • and so on
I then, always include two different stylesheets. One that has only the master stuff and then one that has per-section stuff. If an element starts to repeat through sections, I bump it up into the master common UI. If I use an element only in the main section, I may downgrade it from common to page-specific. This is just a normal overview of using LESS/SASS. The power here is the power to import.
Keep in mind, I am creating several separate stylesheets. Their mixins/vars will not be communicable so if you have a set of mixins you use, you’ll have to include it at the top of every separate stylesheet. The beauty is, mixins/var don’t typically add weight to the project
Here’s how my WordPress example was structured to mimic this project LESS/SASS breakdown:
Since my site is pretty varied, I created a LESS sheet for my blog, the home page, the page, and portfolio with a single page-boot stylesheet to wrap the rest.

Get The Idea?

The idea here is to be very object oriented. Every group of adjoining styles is an object. You add them together and wrap them in a bigger stylesheet. Every bigger group deserves a folder with its own wrapper stylesheet and other stylesheet there. You should only load about 2-3 stylesheets per page which should be your master, section-specific, and misc/imported stylesheet which may be bootstrap, UI kits, and so on. Remember to minify! 🙂


Alright. let’s tackle some sample real-life projects. You’ve already seen my wordpress breakdown, so how about a social network?

  • master – typography, basics, scaffolding (grid), comments, likes, general UI skin (think like buttons etc. on facebook)
  • profile page – front-profile, sidebars, feed overrides for profile
  • photo – photo upload modals, slideshows, etc.
  • events
  • groups
  • forums
  • etc.

Simple, right? The main thing is to realize the right break points for stylesheets so that they can always be manageable.

Keep In Mind

Keep in mind:

  •  ALWAYS compile before launching, having the user-side compile or the server compile every single time is wasteful.
  • Try not to overdeclare, that’s a big no-no. You’ll get into trouble (especially on big projects) where your CSS will slow down the page rendering.
  • multiple imports may cause issues when compiling. I had some weird trouble with LESS while SASS didn’t give me any problems.
  • Compile only parent-level stylesheets. Don’t create clutter by compiling the rest, it won’t be used.

Happy LESSing and SASSing!