CSS Naming Conventions: Fewer Rules, more Fun

The ease of using straightforward CSS Naming Conventions in large scale projects.

Naming Conventions have proven to be a great guide line for all kind of things people want to name. There are Systematic Names in biology and chemistry, and a specific scheme for postal codes which are kind of a naming convention for regions. Also products have a scheme for getting their names: Books for example have ISBN. Or, more specific, Nokia has naming conventions for their products.

Naming conventions in code are called Identifier Naming Convention and are well known by most software engineers for a long time. In CSS there we saw a push in Naming Convention establishment within the last few years with concepts like SMACSS, OOCSS and BEM which provide a decent standard for naming elements.

In general these guide lines are based upon how you build your styles and what type of granularity you want to support within your code.
The concept of what I call Structured Components has proven to be a good one in all of the above named conventions. Structured components consist of the following elements:

• Components: A page module that has a certain purpose and is a wrapper for its children, in example a modal or a slider can be a component.
• Nested Elements: Parts of which a component can consist, sometimes similar across components.
• Variants: A component and its containing elements which are modified in a certain way.
• States: The state of a component or nested element is modified by user interaction, for example a disabled button.

The Naming Conventions named above, mainly BEM in my opinion, abstract this model to provide a complex ruleset for each and every case you run into while working with HTML and CSS. For sure you want to nest components into each other to be more flexible and to have even more options.

Most of the time I work with CSS and HTML I apply some sort of naming pattern for the classes in use and enforce them with my team mates.
On one hand concepts like BEM or SMACSS provide a good structure for the way you code. But on the other hand they seem to become a bit complex and sometimes hard to understand. You try to provide a ruleset which describes each and every little detail to prevent falling into a trap for very rare cases and some naming issues.

I suggest we don’t try to find a technique without any loopholes but rather focus on the main purpose and provide a guide line which is easy to understand and based upon what has proven to work great: The modal of a Structured Component.

Let’s apply this concept to a more minimal approach by naming just the most necessary rules.

Components

Components use a name:

.component {…}
.component-name {…}

A name can consist of different words separated by a “-” (dash).

Variants

Variants of specific component are defined as follows:

.component--variant {…}
.component-name--variant-modifier {…}

A variant is divided by “--”(double dash) from the main component’s name. It can contain “-”(dashes) to separate words from each other.

Nested Elements

Elements can be nested within a component:

.component__link {…}
.component-name__link-element {…}

A nested element is divided by “__” (double underscore) from the main component’s name. It can contain “-” (dashes) to separate words from each other.

Modifiers / State Indicators

A component can be modified via a separate class:

.component.is-active {…}
.component-name.has-children {…}
.component.js-selected {…} /* For behavior applied via JS */

A modifier class is a verb combined with the purpose it has to describe the state of the component, which are separated with a “-” (dash).

We use these guide lines within my current project and it works well with our team. This does not mean it will work with every other team too. We run into questions and edge cases all the time. But the general outcome of applying these straightforward guide lines is positive.

You only have to make sure to get everyone in your team on board and stick to the rules.

Conclusions

Reduced guide lines can help build web applications and web sites with a more common understanding but leave developers with a decent freedom to react to problems in their own way. In my opinion with this subset of BEM’s conventions a team can focus better on the most important bits of guide lines without the need to understand a lot more than the basics of the Structured Component modal.

In any case I recommend being open with other techniques. When you join teams that already established guide lines it is most important to stick to these rather than improving what is already in use. This is key for enforcing good code quality.

What are your experiences with guide lines like these and how does it affect a larger team? Do you see pitfalls with reducing naming conventions? Let’s share them.