Photo by Mr TT on Unsplash

Modern web apps have an incredible number of elements to them. Like the image above, these elements are all different in some way, often made up of smaller elements.

For a single developer, writing CSS for something like this could seem relatively elementary. However, when working in a large team on an ever-changing product, the complexity comes when trying to keep the code scalable and self-explanatory.

Finding a solution

The frontend community at Bloom & Wild meet on a regular basis to discuss changes and improvements to our codebase. As a naming convention would effect all members of the community, this was the place to deliberate such changes.

We met with our laptops, a white board and good whit to discuss multiple naming conventions and (S)CSS file structures. We usually take turns to propose or comment and use the whiteboard or online resources to assist.

Our Solution

It ended up taking more influence from BEM than we thought. We did however come to the joint decision that it was a bit dated and needed a revamp.

A new baby was born and we named it CEMSU (pronounced Semsu). This stands for:

Component .burger-menu

This class name matches the Angular @Component element after the prefix so <bw-burger-menu> has an immediate child with the class .burger-menu with all elements inside. This has to be unique across the entire app.

Element .burger-menu__item

The Elements are all the parts that make up the Component and belong only to that Component. These are not hierarchical so can be anywhere within the Component. You want to put an Element inside another Element? do it.

Modifier .burger-menu--primary or .item--has-children

These come in 2 flavours. There is the Component Modifier and the Element Modifier. If there are multiple instances of either a Component or Element with cosmetic differences, that’s where Modifiers come in. A Component Modifier is applied to the root of the Component. An Element Modifier is applied to the Element itself — with potential changes to Elements within it. Don’t worry, there are code snippets below. I promise.

State .is-current

States react to realtime events that occur while the app is being used. These are component-specific but don’t necessarily have to be unique.

Utility .u-font-serif or .u-flex-wrap

Utility classes are app-wide and can be used anywhere. They can affect any style property of an element and have have a descriptive naming convention.

See these in action below

Example Component

For this example, We will look at a slimmed down version of a component we have on our site. The infamous Burger Menu. I have commented on lines pertinent to this article.

Here’s the HTML

And here’s the SCSS

We are ever evolving our tech and processes and think this is an awesome step in the right direction. As our app gets larger, the importance of such conventions becomes oh so clear. If you have any thoughts or comments on this convention, don’t hesitate to leave us a comment.