Method to the CSS madness

I’m sure that most people who have worked with CSS or even legacy HTML can relate to the pain of CSS breaking as soon as you change any tiny element of the HTML. This is not how it needs to be, all we need is a little guidance. Enters SUIT. SUIT is one of many stylesheet naming methodologies which relies on structured class names and hyphens to add transparency to your CSS. It may seem a little counter intuitive, that when CSS is such a simple language, why would you choose to add a layer of complexity that SUIT brings? Unlike preprocessors, naming methodologies don’t add extra features, abilities or extensions to your code, but what they do bring is structure. Structure which guides us in creating loosely coupled, maintainable and readable code. And who wouldn’t want that?

Basic Principles


This is the CSS that is going to be used specifically for our HTML components and will be structured as:


The namespace is optional but advisable. It will remove the potential of your component names clashing with external libraries.


A pascal case representation of your component. It is important to try and not be contextual.


A camel case class which will add additional presentation rules to your component.


A camel case class which will add additional presentation rules to decedents of a component.


You can add states to your objects using:



Utilities are like traits. They are independent classes which can be added directly to any element.


To identify the class as a utility


Can be used to identify responsive variants on utilities. For media queries - sm: small, md:medium, lg: large.


A camel case class which will describe the additional rules to apply to a component.

Jumping in


I will use the same example I have used from my previous post on BEM, and apply SUIT for a simple comparison.

Our basic component is a signup form: <ComponentName> using the al- [<namespace>-]


<div class=“al-FormBlock”>

A light modifier can be added to this component using [–modifierName


<div class=“al-FormBlock--light”>

It’s descendants, the text-box and button can be identified using -descendentName]



<div class=“al-FormBlock”>
  <input class=“al-FormBlock-textField”>
  <button class=“al-FormBlock-button”></button>

The state can be defined using is-stateName element2-mod.png

<div class=“al-FormBlock”>
  <button class=“al-FormBlock-button is-hovered”></button>

Finally we can add a utility which is going to stretch any component it is applied to to 100% width using u-


<div class=“al-FormBlock u-fullWidth”>
  <input class=“al-FormBlock-textField”>
  <button class=“al-FormBlock-button”></button>

So in short, by creating these simple and clearly named classes, a new developer can step into this HTML and create multiple variants of this form without even looking at the css. They will be able to move it anywhere in the site, invert the colours, change the size and add as many fields and buttons as they please.

Still curious

SUIT, like all other naming methodologies has it’s downfalls. I however, continue to see the positives outweigh the negatives, so will continue to explore this area. In terms of SUIT in comparison to BEM, each method has its strengths. I do miss the visual cues from BEM of the double underscore, but the utilities in SUIT are very valuable. The next steps forward for me at this point is to use a hybrid of the naming methodologies which work best for our team.

Although SUIT and BEM solve many problems, I am at the core an OOP programmer and am still curious as to how I can stretch this language to work best for me and the rest of the team here at Adaptive Lab. So next on my list for experimentation OOCSS, for more modular, efficient and reusable code.

You can find the BEM blog that I’m talking about here.