CSS methodology and frameworks
OOCss, BEM, Smacss are the 3 main CSS methodologies for scalable maintainable frontend code… Here are my thoughts on them.
Due to recent changes in my work life, I’ve been faced with a problem I never really considered before : someone is going to use my code to do something with it.
If you’re a student, a freelancer or don’t work with a team of people, you might not have considered that fact either, but for me this have been a shock : how can I provide nice code that would be easy to use for the other members of the team ? Code that scales, no matter how big the project is ? Code that I can write, forget and change later without being lost ?
Css Methodologies to the rescue!
In order to fix all that, I searched for Css frameworks, not the kind that comes with a bunch of classes and some doc, the kind that tells you how you should do stuff, defines a process for writing code, conventions.
The main ones I’ve found are BEM, Smacss and OOCss. All 3 of them take different approaches to tackle the same problems and I guess it’s more about which one you prefer, rather than a “right one”.
Probably the most famous one, OOCss stands for Object Oriented Css. To me the name is a really bad choice. That’s irrelevant, and doesn’t change the usefulness of the methodology but it’s bad enough to be pointed out, it bring more confusion for coders and implies ideas and behaviours that simply don’t exist in CSS.
The core idea is to seperate structure and skin, content and container. The objective being to change them as will and create a frontend framework with re-usable components
Used on really big websites, it’s the one that looked the most promising to me… at first.
There 2 reasons that made me not use it, the first one being the lack of tutorial. You can find explanations for the idea behind it, a lot of videos of conferences, blog posts, but no real-life example, no clear thought process behind an actual piece of code…
The second reason is the concept of DRY applied to css, basically avoiding repeating the same propriety-value pairs, by creating classes… While this makes sense (DRY -> smaller files), it also makes the files more difficult to read ad browse, and the code more difficult to maintain. Sure it would be nice to change all the elements with a red background, to have it blue instead. But if you want one to be blue, you have to create a new class, and change that class in the markup. This can easily get complex and painful if you need to browse a lot of template files and stuff.
The second-bis reason, is that the DRY principle can be applied through minification. I have yet to find a tool that would re-organize selectors to minimize repetitions of similar propriety-value pairs, but it’s totally possible, and would fix this issue, without requiring large amount of classes applied to html elements, and difficult to browse css files.
BEM stands for Block Element Modifier, and is a methodology, a naming convention and a set of tools.
Unlike OOCss, it doesn’t aim at total modularity, but the opposite : namespacing (through classes names), creating independent modules of css code that don’t interact with each other.
To me, independent modules is a simpler approach and while it fails to provide the modularity of OOCss, it gives easier to manage files.
The naming convention is a bit weird (using -, –, __ as different kind of separators) but it’s effective.
The tools included in BEM are mostly related to XLST, templates, doc and that kind of stuff, I didn’t really get into that because that wasn’t hat I was looking for, but I guess they can be useful, definitely worth trying.
One thing I’m not really fan of in BEM is that the class name will easily get really long, and the longer they are the more likely you are to make mistakes, the longer the files get.
As you probably guessed, this is the one I settled with. Like BEM it creates independent modules, the only naming convention is to prefix all the classes of the same module with e 2~4 characters long tag such as “nav” or “mod”.
Modifiers in BEM and states in Smacss are similar, but Smacss uses global states, while BEM’s modifiers are namespaced and limited to a module. This is probably more a matter of taste, I like the idea of having consistent states for all my elements where it makes sense.
In it’s architecture, Smacss is also quite flexible, you can go with 1 single css file, or 1 per module, or a folder, or anything you like (assuming you’re using some kind of merging/minification tool to get only 1 for production).
The way I use Smacss
I use it with LESS as a pre-processor. I just like LESS and it allows me to create a lot of files and still have them all merged and minify when I save any of them.
I create a folder for each module containing at least a css file for the style of the module itself. Along with this file, I create an HTML file containing the doc of the module.
Writing docs can take some time (last one took me all afternoon for a rather small project) but it saves a lot of time when you have to change something, and it will help next developers understand what you did, and hopefully improve it, not break it, and why not follow the rules you established.
Then, if I need to, I create 1 stylesheet per skin, if the same modules will need to be displayed with different themes applied. When I have only 1 skin, I put it directly in the module’s css file.
As I said in the beginning, they all are interesting, and even though I have my preferences, they’re all worth giving a shot, try them, read their docs and see which one fits the best in your workflow, which one seems the best for you.