Creating larger projects in CSS is quite a challenge. We have to take into account the cascade and CSS specificity, remember about classes that should be reusable and shared across the whole project, avoid the !important notation, and take care of proper naming. Methodologies such as BEM, SMACSS, or OOCSS help with many things, as do preprocessors such as LESS and Sass.

Even so, methodologies and preprocessors alone will not always solve all problems. When preparing any programming project, sooner or later we will run into problems related to the architecture of our solutions. Architectural changes will be forced on us by the characteristics of the project itself. Source code that has grown too large will become unreadable if we do not do something about it.

In this post I will present my favorite approach to building styles in CSS. My solution is based on Sass, BEM, and the 7-1 pattern.

The Concept of a Component

A component, understood as part of the graphical interface of our project, is an independent, reusable element that performs only one task. This definition of a component places it very close to the definition of a Block in the BEM methodology. The idea of dividing interfaces into sets of components should lead us to creating more orderly CSS code. In principle, anything can be a component, as long as it meets the requirements above. Creating components and placing them in one CSS file still will not solve the problem of code that has grown too large, so it is worth adding the assumption that each component is an independent file.

At this point, it is worth mentioning preprocessors, for example Sass. We can add new components to new files, starting their names with _, and thanks to @import we can later compose them into a whole by importing the ones we need.

The 7-1 Pattern

On sass-guidelin.es we can find a lot of tips about ways to power up our Sass so that it is as effective as possible. One of the subsections concerns the proposed 7-1 pattern. The 7-1 pattern originally came from the assumptions of the SMACSS methodology, which contains guidelines on how to build scalable and modular CSS. According to the 7-1 pattern, we have 1 main file that contains only information about the other files that need to be loaded for our project to work correctly. The 7, in turn, means the 7 most important groups into which we divide our code files.

Kitty Giraudel, the creator of this concept, proposed dividing a project into 7 groups:

• base
• components
• layout
• pages
• themes
• utils
• vendors.

You will certainly find the details of what should be placed in individual directories on Hugo's website - sass-guidelin.es. From my side, I will add that, in my opinion, the idea of such a division makes a lot of sense, although in most projects the 7 directories can safely be reduced to 5. I practically always skip themes, because few projects I work on support many themes, and pages. I treat every interface element as a component, so individual pages are only collections of different components.

What Is BEM Doing in All of This?

BEM as a methodology supports writing code that is easy to maintain, although probably everyone who has worked with it will confirm that the hardest part of working with it is inventing more names for blocks. Block names should be unique, which means they should not repeat in our project. Sometimes this is hard to achieve. In addition, it can sometimes be difficult to distinguish whether a given CSS class is a component, a layout fragment, or a helper class. That is why in my projects the classes I create are always prefixed with one letter. For example, I would like to create a login form component that I will place in the components/ directory:

.c-login-form {
 	border: 1px solid;
	background-color: $base-color;

	&--sidebar {
		border: 0;
		background-color: transparent;
	}

	&__input {
		display: block;
		padding: $gutter;
	}

	&__submit {
		appearance: none;
		border: 1px dotted;
	}
}

Notice the structure of the SCSS file itself. I use nesting, which is available in Sass, while at the same time my output file will be flat. The prefix for this component is c-, because it will go into the components/ directory. In addition, all repeatable elements are contained in variables. This notation guarantees that I can easily find my component files, that by changing them I will not change anything other than what I want to change, and that changing shared elements in base files will also affect this file.

Summary

It is always worth thinking through your CSS project before you start writing. You need to be one step ahead of your CSS so that you do not fall into its trap. Remember that the time you spend before writing any CSS class is time that will pay you back with interest during further project development or debugging. Decisions made in a hurry become very difficult to change over time.