A few weeks ago I wrote about how we've been trying out BEM CSS Architecture here at the Lab, and the positive experience we had in using it. I concluded that BEM had "started us on a journey that has ultimately made all of our developers more considered in how they write their CSS, and to take more joy in the architecture of this seemingly simple language”. This remains true, and since then I have been taking a closer look at SUIT, a new flavour of stylesheet naming for my next project.
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?
This is the CSS that is going to be used specifically for our HTML components and will be structured as:
[<Namespace>-] The namespace is optional but advisable. It will remove the potential of your component names clashing with external libraries.
<ComponentName> A pascal case representation of your component. It is important to try and not be contextual.
[—modifierName A camel case class which will add additional presentation rules to your component.
|-descendentName] 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.
u- To identify the class as a utility
[sm|md|lg-] Can be used to identify responsive variants on utilities. For media queries - sm: small, md:medium, lg: large.
<utilityName> A camel case class which will describe the additional rules to apply to a component.
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>-]
ruby <div class=“al-FormBlock”> … </div>
A light modifier can be added to this component using [–modifierName
<div class=“al-FormBlock--light”> … </div>
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> </div>
The state can be defined using is-stateName
<div class=“al-FormBlock”> <button class=“al-FormBlock-button is-hovered”></button> </div>
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> </div>
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.
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.