This will be our final entry in the CSS Methodologies series of blog posts. In the other posts, we’ve already talked about:

And to recap, our three example users are:

  • Single user/hobbyist/lone-ranger (Alex)
  • Small agency/friends collaborating/3-4 developers (Tuco)
  • Large agency/corporation/5+ developers (Mary)

And this week we’ll be talking about…

##ACSS (Atomic CSS)

This is probably the least well known/talked about CSS methodology, but probably the most used. If you are familiar with web frameworks such as Bootstrap, then you’ll have seen this.

This is basically the concept that every CSS class you write is reusable everywhere, and you should never repeat anything.

All your CSS classes are made up of tiny snippets that do a single thing, and then you add these to your markup as you need them. For example, some ACSS classes you might see in the wild:

.mt-20 {}
.pl-10 {}
.fl {}

These may look familiar, or you might be thinking “WTF are they supposed to be?!” Basically, the .mt-20 class adds a margin-top of 20px. See if you can figure out what the other two are.

####Good points:

  • Lets you create prototypes quickly
  • Very DRY
  • You can extend classes with these classes using a CSS preprocessor

####Bad points:

  • To make a small change, you’ll probably need to write a new class, or add a class to markup
  • Anybody coming into a new project will find it very hard to know where things are
  • Changing an old project will require relearning what the classes do
  • Un-semantic and verbose markup
  • Very difficult to debug
  • No OOCSS

###Who should use ACSS?

Alex - Sometimes
When building short lived, or prototypes ACSS in the form of a web framework can make it very easy to mock something up very quickly. Usually without having to worry too much about how something looks as the classes will be defined for you. For anything that may potentially be changed in the future, don’t use ACSS.

Tuco and Mary - Prototyping only
ACSS classes should really only be used for creating prototypes - but even then, it’s probably not a good idea as those prototypes will often become something more long term, and you’ll have to trash everything you’ve written.

Further reading:


Pretty much all of the CSS methodologies we’ve talked about in this series can be used interchangeably - BEM and SMACSS are often used together to rigidly define how a team should organise their CSS.

Everything we’ve covered can also be changed/modified and used in however way works best for you. You may decide you’d rather use a different character in BEM to separate your classes - and that’s fine - it’ll work in the same way. Or you may decide you don’t like the names base/layouts/modules/themes and change them to global/views/mixins/variations.

I hope you’ve got a better idea of what CSS methodology you should be using, and why you probably shouldn’t be using others.

If you think I’ve missed out any CSS methodologies, please comment below. I look forward to any new CSS methodologies that start appearing in the future!