CSS With Purpose: Mindful Styling With SMACSS
A glance at the Scalable and Modular Architecture for styling your sheet.
Photo credit: Michael Dziedzic via unsplash.com
Welcome to the introductory bit of the blog post! This post assumes you know a.) What CSS is, b.) Some basic HTML, and c.) That you’ve kind of been winging it up til now regarding your process for writing a CSS file. Hey, I get it. You’re just trying to style your site real quick-like, and you can just use child element selectors, toss some id’s around in your HTML, or come up with weird and / or long class names while you figure it all out. You’ve been coding The Real Stuff, making the logic behind your app or website, and maybe styling is kind of an afterthought. No more!
SMACSS: Scalable And Modular Architecture for CSS
Before moving forward, if you haven’t been pronouncing SMACSS as “SMACKS” in your head as you read, I’ll give you a second to change your ways and really start livin’.
Ready? Cool.
So, SMACSS was created by Jonathan Snook (who runs a cool blog, if you’re interested), and it’s purpose is pretty clear: clean, orderly coding that lends itself to team collaboration and easy scalability as a result. I understand that scalability may not be everyone’s top priority, but these are sort of “best practices” for vanilla CSS anyway. Everyone can benefit from organization, I mean, just look at Marie Kondo. We love her.
SMACCS Basics
As the name implies, this is a great method if you’re working on a big site, but starting small. If I had to boil the methodology down to its core, I wouldn’t have a problem because our boy Jonathan Snook has absolutely given us the hookup there. That’s right, he wrote a book on his ideas, and it’s free to read on his site. What a guy. If you’re still here because you enjoy my company and / or are intimidated by a body of writing larger than, say, a six-minute Medium article (thanks, by the way), please allow me to guide you on these core sets of rules:
Base Rules
These, I think you’ll find, are pretty easy. Generally speaking, these are your own rules for how you’d set up the defaults for HTML if you could. In other words, you’ll use tag selectors a lot here, probably exclusively. What would your links look like? Margin settings on your regular divs? How about when you hover over a button? Now’s the time to implement that kind of stuff. If you’re unfamiliar with CSS Resets, I’ve got a great article my friend Josh-Gotro wrote to get you started on that idea. That’s where this kind of stuff gets added to the file.
Layout Rules
Again, I find myself thinking that you probably know where this is going. These rules apply to the layout of the page, and are largely structural in nature. There are two types of layout styles: major and minor. Major layout styles like header and footer can use id selectors, but as a general rule use class selectors when you can for minor layout styles. In fact, using class selectors is better in general according to SMACSS, so you’ll definitely see that sentiment expressed a few times.
Minor layout styles aren’t really specified here, Snook says that the distinction is based on reuse. I’m guessing that groups of similar or repeating elements that have a primarily layout-related function are fair game for minor layout rules.
Module Rules
Modules are less self-explanatory, so let’s figure out what they are before talking guidelines. The most distinguishing features of modules are that they are independent. They should be able to be moved around without losing styling. Examples being carousels, forms, any widget you make that you could say has a distinct function by itself.
Rules for these are, per usual codification, stick to class selectors. No id’s or element tag selectors if you can help it. He gets into handling the module’s child element stylings in the book (and best practices for those as well), but that’s too specific for our purposes here.
State Rules
State rules are a little goofier. They refer to those classes that are added (or removed, or modified, etc.) to an element by JavaScript while using the app or site. A side menu might be hidden by a button that changes its class to “hidden-menu”, a picture may be expanded or shrunk down. The main things to note about these are that they usually apply to a layout or module style, and they depend on JavaScript.
This is the (perhaps only) situation that Snook considers it valid to use !important for styles — for the simple fact that state styles usually completely override other styles on an element. Other than that, most of this section revolves around recognizing a state when you see it and where to put the code (spoiler: you’ll want to put that by the styles for the module or layout the state modifies).
Theme Rules
These aren’t really worth going into much more than to say that they revolve around the colors, fonts, images, and other design-y features that designate the overall “feel” or “vibe” of the app. You could make use of different sets of themes (a popular one being normal vs. night mode) that activate at the push of a button (changing the state, you might say). He recommends keeping these in a separate file, but doesn’t give a lot of hard rules on them as they lend themselves less to structure.
Is that everything? Of course not.
Snook’s book goes into detail about these core rules first, then into more specific cases and even touches on how browsers read documents and CSS, pre-processors (LESS and SASS) and his opinion on how / when to use them, and complications regarding inheritance. He also provides a video of him troubleshooting a frustrated Twitter user’s CSS (the user was trying to implement SMACSS, but was having trouble with the process) step by step, which is a great watch to see how simply organizing a CSS file can remove a lot of stress (and uses of !important) from your experience. I feel like a better frontend developer from reading these concepts and will be applying them going forward on my projects.
Alright, let’s wrap it up here. What should you do?
Whatever you want. Didn’t like these ideas? Keep doing CSS your way, or look at any number of other valid methodologies out there. No one will tell you that SMACSS is the end-all be-all for styling, you can use it or forget it immediately. Or use pre-processors, or use frameworks. There’s no right way to do this stuff; you know that.
If you’re interest is piqued by the basic ideas of SMACSS and wonder if it’s worth reading the whole book, I’d say it is completely worth checking out. It’s free here, and it has plenty of examples to get you thinking in terms of how you’d handle actually implementing this stuff. It’s a great read from a guy that knows what he’s talking about.
Let me know if I missed something, said something dumb, wrote a typo, misunderstood anything, offended a sentient Twitter bot, misspelled my own name — anything! I appreciate all feedback, and am at your eternal mercy, Dr. Internet!
Thanks for reading! See you next time.
