CSS Methodologies

Pavan NVR
6 min readAug 28, 2019

The Cascading Style Sheet ( CSS ) is highly used to combine the art of design with the art of programming.

CSS is a stylesheet language used to describe the presentation of a document written in HTML or XML (including XML dialects such as SVG, MathML or XHTML). CSS describes how elements should be rendered on screen.

CSS is used to style and layout the web pages — for example, to alter the font, color, size and spacing of your content, split it into multiple columns, or add animations and other decorative features.

CSS Code architecture is most important when we want to write clean, readable, maintainable and organised code. The most popular CSS design patterns are SMACSS and BEM.

These methodologies following DRY (“don’t repeat yourself”) principles. DRY is a software development principles aimed at reducing repetitions in code.

SMACSS: SMACSS (pronounced “smacks”) is more style guide than rigid framework.

SMACSS is a way to examine your design process and as a way to fit those rigid frameworks into a flexible thought process. It is an attempt to document a consistent approach to site development when using CSS. And really, who isn’t building a site with CSS these days?!

This methodology focuses on 5 main types of structures to organize our CSS:

Base: Base styles are, that apply to base selectors. These should be very simple and incredibly broad styles, such as font color and family, link styles, etc. Something like this:

body { font-family: sans-serif; }

p { font-size: 1rem; }

a { text-decoration: none; }

Layout: Layout styles are meant for logic-less container elements that are solely included in your HTML to provide positioning, padding, or other layout-based purposes. By default, SMACSS recommends us to begin our layout styles with the l- prefix:

.l-container { max-width: 58rem; margin-left: auto; margin-right: auto; }

.l-horizontal-padding { padding: 0 1em; }

Module: Modules will make up most of the CSS of our web pages. We should style a block of HTML code with independent, semantic content as a module with children elements. Something like this:

.menu { list-style: none; }

// child element of menu

.menu-item { float: left; padding: 1em; }

SMACSS suggests us to keep our module names short.

State: States are the styles that should be triggered by Javascript (i.e. showing an element, hiding an element, marking an element as active, etc.) — and should normally begin with the is- prefix:

.is-hidden { position: absolute; left: -999rem; }

.is-visible { position: static; }

Theme: The purpose is to provide styles for various themes — where the core styles of a series of pages stay the same, but small things may change like background colors, fonts, etc.

Folder Structure

SMACSS doesn’t place much emphasis on how we should structure CSS files (which is drastically different from BEM):

base/

layouts/

modules/

states/

app.scss

Using this as a folder structure, we would just create files for each style type in each respective directory

BEM: ( Block, Element, Modifier)

Compared to SMACSS, BEM is simpler to understand — but it’s much more rigid in how you structure your code and files. In BEM, every style is a part of a module — no base styles, layouts, themes, etc. You just have blocks, elements, and modifiers.

Blocks: Block is the main component element, i.e., the highest level of a module.

Something like a menu:

.menu { list-style: none; }

Elements: Element is a descendant of Block, i.e., represents the actual child items inside of a block. Elements always begin with the block name, followed by two underscores (__) and a suffixing name:

.menu__item { float: left; padding: 1em; }

.menu__link { font-size: 1.25em; }

Modifiers: Modifier styles are applied to both blocks and elements, and are strictly meant to handle the subtle differences that two similar blocks or elements may have. For example, a menu link may be white — or it may be blue:

.menu__item — white { color: white; }

.menu__item — blue { color: blue; }

Modifier styles always start with the full block or element name, followed by double hyphens (–) and then the modifier name.

BEM provides a way to arrange our CSS classes into independent modules. When we discuss BEM, we often focused mainly on the naming convention. One great thing about BEM is specificity control.

The most common way to represent BEM is like below:

.block {}
.block__element {}
.block — modifier {}
.block__element — modifier {}

Example:

<div class=”mat mat — modifier”>
<a href=”#” class=”mat__body-wrapper”>
<img class=”mat__image” src=”” alt=”” />
</a>
<div class=”mat__content”></div>
</div>

// With CSS — which will output the code above

.mat {…}
.mat — modifier {…}
.mat__body-wrapper {…}
.mat__image {…}
.mat__content {…}

// With SASS — which will output the code above

.mat {

& — modifier {…}
&__body-wrapper {…}
&__image {…}
&__content {…}
}

By using the naming convention stated above, we are automatically flattening our specificity to .class single selectors

Like SASS, BEM will also help us enhance customization modularity. We’ll use it as a way to standardize our stylesheets and make it easier for developers to maintain them through time.

BEM Folder Structure

This is where BEM heavily differs from SMACSS. BEM suggests that every single block, element, and modifier should have its own CSS file. So as we start to build out our project, we’ll quickly create detailed file structures like this.

The above structure is very organized, but to create a new file for every new class basically is a little extreme for us. This is one reason BEM is difficult to fully implement in the recommended manner.

The Similarities between these two Methodologies are:

  • Never use ID selectors. CSS class selectors should make up the majority of our styles.
  • CSS selectors should stay flat — don’t nest them (unless you have a good reason).
  • Both methodologies focus on a module-based system of organizing the majority of our CSS. i.e., we should architect our CSS classes in a manner that takes advantage of building repeatable HTML blocks that have a semantic purpose.

Note: So, The best way to maintain our CSS is, to take the core concepts of BEM and SMACSS and combined them in a way that made sense to modularize our CSS.

BEM’s recommends how code blocks should be structured. Blocks, elements, modifiers. Building CSS class names by following this design pattern really help us to think about CSS code in a reusable block-based manner.

SMACSS architecture that leverages the power of base, layout, and state styles

– and instead of SMACSS’ module styles, we can substitute them completely with BEM styles — blocks, elements, and modifiers.

Some of the best practices to follow while writing the CSS code

  • Follow appropriate Naming conventions
  • Don’t use px values, use percentages
  • Maintain component level CSS
  • Make the selector chain three or less
  • Don’t repeat CSS properties, create common classes to reuse the classes
  • Delete the unnecessary descendant selectors
  • Use class names as key selectors, avoid ID selectors
  • Reduce white spaces in the CSS files
  • Don’t use !important for the selector based CSS properties
  • Use an indent of two spaces for better readability
  • Class names should be in lowercase, with words separated by underscores. ex: my_class-name {}
  • HTML elements should be in lowercase ex: body, div.

--

--