There are almost as many CSS Classes methodologies today as there are CSS or JavaScript frameworks. But unlike CSS or JavaScript frameworks, which are usually all or nothing and come with a bit of baggage, a CSS methodology is more of a philosophy about the relationship between HTML and CSS than a prebuilt codebase.
It seems that almost every day you hear about a new approach using some new namespace, leveraging data attributes, or even moving all of the CSS into JavaScript. The great thing about all of these methodologies is that they all bring something interesting to the table, and help you to learn something new about how HTML and CSS Classes can be intertwined.
There is no single perfect approach, and you might find that one project fits best with one, and another project works better with another. There is absolutely nothing wrong with just creating your own methodology, or starting with a popular one and then modifying it to your taste.
So if you are wondering where to start when deciding on your own approach, it is best to take a look at a few of the more prominent methodologies and see what does, and what does not resonate with the project you are about to tackle.
OOCSS Approach
The following snippet shows the Object-Oriented CSS Classes approach to creating an HTML toggle.
<div class="toggle simple">
<div class="toggle-control open">
<h1 class="toggle-title">Title 1</h1>
</div>
<div class="toggle-details open"> ... </div>
...
</div>The two main principles of OOCSS are to separate structure and skin and to separate container and content.
Separating structure from skin
Separating structure from skin means defining visual features in a way that they can be reused. The simple toggle element shown in the preceding snippet is small and reusable in many different situations.
It can be displayed using various skins that will alter its physical appearance. The current skin of “simple” might have square corners, but the “complex” skin might have rounded corners and a drop shadow.
Separating container from content
Separating containers from content means stopping using location as a style qualifier. Instead of styling tags inside of some container, create reusable classes like toggle-title that will apply the required text treatment regardless of what element it is used on. This way you can let an H1 look like the default H1 if no class is applied to it.
This approach is very useful when you want to provide your developers with a large set of components that they can mix and match to create their UIs. A great example of this approach is Bootstrap, a system full of small objects adorned with various skins. The goal of Bootstrap is to create a complete system that is capable of creating any UI that a developer might need to put together.
SMACSS Approach
The same toggle component written in Scalable and Modular Architecture for CSS would look like this:
<div class="toggle toggle-simple">
<div class="toggle-control is-active">
<h2 class="toggle-title">Title 1</h2>
</div>
<div class="toggle-details is-active">
...
</div>
...
</dl>Although it shares many similarities to OOCSS, SMACSS is an approach differentiated by the way it breaks the system of styles into five specific categories:
Base
How markup would look without classes applied to it
Layout
Dividing the pages up into regions
Module
The modular, reusable parts of your design
State
Describes the way that modules or layouts look under given states or contexts
Theme
An optional layer of visual appearance that lets you swap out different themes
In the preceding example, we see a combination of module styles (toggle, toggle-title, toggle-details), submodule (toggle-simple), and state (is-active). There are many similarities between OOCSS and SMACSS in how they create small modular pieces of functionality. They both scope all of their styles to a root-level class and then apply modifications via a skin (OOCSS) or submodule (SMACSS).
The most significant difference between the two (other than the difference in how code is structured in a SMACSS approach) is the use of skins instead of submodules, and the is prefixing of the state classes.
BEM Approach
Finally, here is the same toggle component written in Block Element Modifier syntax.
<div class="toggle toggle--simple">
<div class="toggle__control toggle__control--active">
<h2 class="toggle__title">Title 1</h2>
</div>
<div class="toggle__details toggle__details--active">
...
</div>
...
</dl>BEM is the third methodology we are going to look at and is on the other side of the spectrum from SMACSS. BEM is simply a class naming convention. Instead of dictating the structure of your CSS Classes, it only suggests that every element is labeled with a class that describes the following:
Block
The name of the parent component
Element
The name of the element inside of the block
Modifier
Any modifier associated with the block or element
BEM uses a very terse convention for creating these class strings, which can become quite long. Elements are added after a double underscore (e.g., toggle__details) and modifiers are added after a double dash (toggle__details--active).
This makes it very clear that details is an element and that active is a modifier. The use of a double dash also means that your block name could be news-feed without confusing feed for a modifier.
The advantage of this approach over OOCSS or SMACSS is that every class fully describes what it accomplishes. There are no open or is-active classes. While those classes make sense in their context (in a toggle element), outside of that context we don’t have a clue what open or is-active means. While a BEM approach might seem redundant or overly verbose, when we see a class of toggle__details--active, we know exactly what it means: the details element, inside of the toggle block, is active.
Choosing What Is Right for You
In the end, the only thing that matters is to find a solution that works for you. Don’t choose a convention because it’s popular, or because another team is using it. All three approaches give you extremely similar tools to work with, and will integrate with a design system in very similar ways.
Read more: How HTML Relates To Frontend Architect in CMS Structure
Just be aware of the prior art, be able to express why your approach will solve the challenges your project faces, and have a team willing to commit to a single, unified approach. If you decide to use OOSMABEM, then more power to you! I look forward to reading about it.
