My CSS is a mess. I always start off with good intentions but once things ramp up my system falls apart.
I've primarily tried using BEM in the past but have had difficulty sticking to this formula. It's too rigid. I'm looking for something simpler. Something that sets me up to create reusable widgets but also incorporates custom styling in a way that is easy to read and find what I'm looking for. I want equal parts structure and flexibility. But I know that's a tall and basically impossible order.
Do you have a CSS system you love? How do you keep your styling organized in a way that you can look at your html and know exactly where to go to make changes?
*edit: I write my CSS in SCSS. I'm looking for help in organizing the SCSS files and classes.
Top comments (22)
Have you looked at ITCSS? It helps organize your SCSS in a logical way. I find using it in conjunction with BEM and OOCSS is a good combination. There is a good article by Ryan Yu on CSS Tricks called "combing the powers of SEM and BIO for improving CSS" I highly recommend it.
I'll look into it. At first glance it looks similar to BEM: great for setting up reusable components. My problem is I tend to run into cases where components need a little tweaking on a page. Or there are unique pages/sections that only appear once so creating a component for them feels overkill. And then someone decides we need to split a component into two different types and a chain reaction starts of changing every other piece that touches it.
Keeping up with strict frameworks like this makes me feel slow. I'm wondering if there's something out there simpler yet readable.
Let's dig into this a little more! There are two main approaches to organizing CSS: component-oriented approaches like BEM, and inline-oriented approaches like Tachyons. Component-oriented approaches like BEM tend to work well if you're building a design system. But design systems are hard to build! They're hard to build because we can't anticipate all of the use cases that we'll need at the beginning of a project. Folks often struggle when they hit a use case their design system didn't anticipate.
To me, this sounds like exactly the problem you're experiencing. IME, when we butt up against the limits of a design system, we have three options:
Decide we value having a consistent design, and figure out how to use the component WITHOUT those "few little tweaks."
Decide that we value having a consistent design, but realize the component isn't usable without tweaking. So, we then redesign the component for ALL of its use cases. That way, we can make it more adaptable for the needs that we've discovered we actually have. This can be a chain-reaction kind of thing, but it's a GOOD chain reaction! We're refactoring the design because we know more.
Decide that, even though there's value in a consistent design, right now there's more value in just getting the thing done. Here, what I'd actually recommend is NOT trying to fit the variations into any organizational scheme! Create lots of BEM
--variants, add some Tachyons classes, or (GASP) just inline the tweak CSS. I think there's a lot of value in just letting things that are iffy stay iffy.This does two things. First off, code is read more often than it's written. When your teammate comes to it in two weeks (or you come to it in two months), code that looks intentional is going to be imitated and code that looks like hacky bullshit is going to be treated like hacky bullshit. If something isn't ready to be imitated, don't invite folks to imitate it!
Second, and more importantly: if fitting something into a consistent design/organization scheme feels awkward, that means that the scheme is broken. If reworking the scheme to fit the new thing feels difficult, that means we don't know enough to fix that scheme yet. All of the mess? That's INFORMATION. When we try to prematurely organize it because we're embarrassed, we hide all of that information! (We're also likely to build on that shaky foundation; see above.) When the iffy tweak bits wind up being problematic later, we need to UNDO all of the premature organizational work before we can get started organizing things properly. So you're adding work now, and you're adding work later... better just to leave a mess, even if it feels super awkward!
(It can be helpful to have a junk_drawer.scss file next to your shame.scss file.)
The approach I'd recommend here depends A LOT on what's unique about them! Could you elaborate?
That said, you saying that PLUS you mentioning really bad chain reactions has me wondering.... how are you handling layout and positioning? If you're experiencing a lot of chain reactions, to me that implies that your components are tightly coupled to each other. Layout and positioning issues are often WHY un- or semi-related components wind up coupled. If you're not using it yet, you might want to look into switching your layouts to CSS Grid. I've found that the way it simplifies layout logic can really help chain-reaction issues.
I loled at "junk_drawer.scss" and "shame.scss". Lots of good stuff to think about. Thanks!
I highly recommand to look at ITCSS but to make it in a personnal way
Hey Allison,
I normally have something along the lines of config.scss, followed by a few more main.scss (categorised by page), mobile.scss (responsive stuff), elements.scss (for elements + input). Not sure if it is best practice but has some order for me.
I've been using BEM for a couple of years now on a large scale project and I'm very happy about it. But BEM is only a way to organize your CSS on component level. If you need to organize your code on a higher level, you might want to take a look at SMACSS.
I have my SCSS files organised by components. E.g.I have component for page header and I have alongside SCSS file with styles for that. The styles are link to the component file and extracted and merged during build.
Then I have file with root styles (to reset html/body etc) and file with variables (mainly colours).
As such I keep every file as simple as possible (have lint rule to allow max 3 rule nesting and many other rules for company coding standards).
Generally, when the SCSS file is too big, is too big the component itself -> time for refactoring and breaking to multiple smaller components.
And in webpack, we have it set during development for hot reload, so I can change any SCSS file and it is immediately updated in the browser. With the right naming of the file too, so I know, where the css rule origins.
Agreed.
For blocks which receive unique styling, I try to use class names to create a pattern for what belongs to what:
.navigation-button->.navigation-button-text,.navigation-button-icon, etc. This means that those unique styles won't cascade unexpectedly down into other elements later.However, for components which will certainly be reused, I try to use BEM when possible. Not every
buttonwill be abutton.sign-in, so I continue to try and scope my styles using css.If I need something super consistent I'll just try and find a library like Bootstrap, which has already made those decisions for me.
I normally use ITCSS and RSCSS. ITCSS is for files structures and separation of concern/responsibility. RSCSS is an alternative for BEM, but keeping your sanity hehe.
Instead of creating a .massive--class-separated--like-this you can crate simple classes without fear, like .button, .icon and such, because of the use of direct selectors(>).
It really is a good combination and I've used in systems with both angular and React.
Have a look at Tailwind. tailwindcss.com
I don't use it but I have been tackling CSS in a very similar way for years. It's easier to understand the concept by checking their site than me trying to explain everything.
It's about building with utility classes and use composition to achieve your goal.
Most people make too high level classes that take care of too many things at the same time.
Then they need to overwrite them, make variants or create new ones. That's when the mess starts :P
Yeah, the worst thing for me also is the time of changes, or when suddenly there is a need to design a new view, and designer use some new font size...this is the moment, when I want to kill somebody. I really HATE writing additional exceptions and have no idea how to predict situations like that. For example:
I tried to name classess because of their margin/padding from other elements. Created .smallMargin, .normalMargin, .largeMargin...what if in future design there will be something between normalMargin and largeMargin? From one side such naming is easy to remember, but the main downside is case I wrote about.
Saaaame.
Hi Allison,
I tried to use BEM for a small period of time but it seems rigid and limited. For project with a few developers is the best, simply to read and simply to debug.
For beginner developer is simple to learn LESS but for me SCSS is the best! It's complete and for experienced developers is very useful.
First off understand what the mess is. Secondly, develop a plan to solve it. Third find tools that will help you make your plan a reality. Finally, accept it will take time, discipline and commitment to clean up said mess.