I had this idea to document how we write our CSS, and I don't mean how we type properties on our keyboards, or how we utilise copy and paste from dev tools; but how we think, organise and meme at one another.
TLDR: Methodologies help to standardise the way you write and name your CSS classes, making it easier for teams and larger projects to scale and communicate There are so many CSS Methodologies
And then it dawned upon me that I should also talk about different ways you can write and think about your CSS too. So make yourself a brew.
Let's talk methodologies, my wonderful X-men!
The first rule about CSS is you don't talk about CSS.
Well, that's a lie. I always talk about CSS and my love for CSS grid, what I tend not to dwell on, is methodologies.
We all work on projects, sometimes they're small, sometimes they're big. Whether in teams or alone, we have different levels of accountability. You can write the most convoluted code and nobody but you has to know, if you work alone. Working with a team, your accountability grows. You collaborate and your decisions of using tables for layouts will be judged by others, clearly, you needed to use float! (don't do either, use tables for tabular data, floats in blogs with awesomely positioned images).
The bottom line is: people think differently. They feel CSS differently and that's really awesome, but you also need some standardised way to avoid CSS-hell. What if you decide to name all your elements based on all the mutants and your teammates start naming them based on ice cream flavours! Imagine the chaos of debugging this?! This is where methodologies, and adopting an approach, will help. You and your fabulous teammates can think about CSS using different mental models, but you all agree on how to name things, so you get one another and you can work on each other's CSS.
I'm commander Shepard and this is my favourite store on the Citadel
You want in, right? You want to get out of CSS hell, name elements better and generally improve your experience writing code. But, you don't know where to go.
There are a lot of CSS methodologies, and I'm not at liberty to say which one you will need. Most of the methodologies that I've encountered focus on scalability and reusability of code. They have their own quirks and ways of thinking.
The sea of CSS approaches is a bottomless one, behold of a small selection:
- OOCSS - Object Oriented CSS, where we recognise visual patterns and separate them into objects.
- SMACSS - I always want to say snacks, but hey ho. Mostly focuses on organisational aspects of CSS: shared modules, layouts, states. All the good stuff
- Utility First approach - frameworks such as Tailwind are built with utility-first thinking in mind.
- GPS (Global Page Section) - The main aim is to keep CSS scope as tight as possible to specific components of the website. Global elements, page-specific and sections.
- BEM (Block Element Modifier) - and its offsprings which I will cover at a later stage. I promised a guide, you'll get a guide!
- CUBE (Composition Utility Block Exception) CSS - the lovely Bryan kindly pointed me in the direction of this gem! It's a methodology that focuses on the composition of blocks and utilises the cascade heavily.
Like with picking grid over flex, you need to be aware of what you're building. I'm not here to tell you that only one of these approaches is best.
Maybe you care more about pages and their composition, so GPS would be your best friend. If you care about the speed of development - having a utility first mindset. Do you need to develop a design system? Maybe BEM is for you.
Let's wrap this up
There will be more to this. I will talk in depth about each, with examples, just wanted to ease you into this magical world. Feel free to Tweet at me and tell me your favourite methodology, your hell stories and why.
Cover photo Brandi Redd from Unsplash