If you’ve written front-end code for more than a year or so, some of the items on this list might seem obvious to you. However, I suspect this will not be the case for everyone. I have discovered that many very experienced developers have made conscious decisions to avoid styling.
While I don’t think that everyone needs to be great at the full web stack, I do believe that every web developer should have some basic knowledge about how CSS/SCSS work and some common decency about better coding practices when it comes to styling.
With that said, I am writing this for new, as well as seasoned, developers, who have have avoided styling throughout their careers and may now be interested in learning a bit more about it.
Here is a short list of considerations you can make to write better SCSS:
1. Use Consistent Naming Conventions
By far, the most widely known methodology is BEM, which is a convention that organizes CSS rule names with
block-element--modifier groups. In many cases, this works really well, but it definitely requires every member on the team to take a step back and understand what these pieces are. If your team is willing to do that, it’s also a great option because a lot of devs are already familiar with it and may be able to get on board it more quickly.
Other opinionated options are SMACSS and OOCSS, and of course, you can design your own convention, perhaps using the organization or project name in a prefix, or categorizing the rules into categories.
I’m personally a big fan of KISS, which is not a CSS naming convention at all, but a tired old saying about keeping things simple. The SCSS Way describes a great approach to modular SCSS, which honestly seems like the obvious choice if I was trying to keep it simple, while not thinking too hard about it all.
Ultimately, my point here, is that you need to be consistent. Do not mix kebab, snake, and camelCase. Even if you find a solution to some problem you are working on on Stack Overflow or CodePen and copying it works perfectly, please, at the least, refactor it to fit your naming conventions. Like any other code, your CSS/SCSS must be as easy to read as possible and consistent naming conventions makes that possible.
2. Use Spacing Consistently
Again, this might seem obvious, but I’ve worked with some pretty gnarly stylesheets and when you’re knee deep in copy/pasta, with inconsistent naming, rules overwriting rules overwriting rules, and random
!importants peppered in for the fun of it, the last thing you need is inconsistent spacing.
What do I mean by this?
I mean spacing within rules:
- Every property should start on its own line
- There should always be one space after the colon
- There should always be on space after the selecter, before the opening bracket
- Indentation should be consistent
And I mean spacing around rules:
- There should be one line in between each CSS rule
- When it comes to nested rules, I’m torn on if there should be an extra space at the end or at the top level rule, if there are no properties in the top level rule. Whatever you choose, be consistent.
3. Do Not Nest More Than 3 Levels Deep
SCSS is great! With nesting capabilities, you get specificity without having to retype selectors. Not only does typing repeatedly take time, but it makes the code more cluttered. There is no limit to how deep you can nest things (that I’m aware of)!
However, I have yet to find a good reason to into more than three layers of nesting. Beyond that, it is really hard to reason about deeply nested code in any capacity. Do yourself and everyone you work with a favor, a question your nesting if it goes beyond two or three layers. Often time two is more than enough.
4.Organize CSS/SCSS Rules
I’ve heard of people alphabetizing their CSS/SCSS rules. I suppose this could work if you are meticulous about your naming conventions with something like BEM. However, I still have an issue with this because your block names are not guaranteed to be universal. What one person/team calls a ‘logo’, another might call a ‘brand’. In general, you could probably get used this convention, particularly if you work with the same team on the same projects for awhile, but I prefer another CSS organization technique.
I start with base styles first – the ones that are usually more generic and applied to elements throughout the application or component (if I’m working with encapsulated components, which I usually am, these rules still apply ). Then, I order the rules, roughly, in the order of the elements that they first affect.
This method isn’t perfect. I may have a rule that affects something at the top and the bottom of the code or it might be that an element might move. Still, with this thinking as a driving principle, I get a better idea of where to look, if I need to find something in my CSS/SCSS.
Ultimately, regardless of the organization methodology sounds better to you, I just recommend that you pick one and use it. Just adding styles to the end of, or in random places throughout a document, gets to be unsustainable pretty quickly.
5. Do not Overwrite Classes from your CSS Framework
When you first learned about Bootstrap and you didn’t quite read the docs all the way and you just wanted to get it to work, you might have gone about it this way: include the compiled CSS in your own project and overwrite the styles in your own CSS, because certainly, you know that in the rules of CSS, he who declares last, wins.
Your own CSS might have had rules like:
This might seem harmless, because after all, you’re following the rules of CSS, and you’re understanding that this overwriting is happening.
Here are some problems with this approach.
- If someone new joins this project and they are familiar with the way that the `card` class works in CSS, they are going to have to do some extra investigating, to understand why the card class in your project is working differently.
- As a general rule, future you is not going to remember what present you was thinking. You don’t want to make future you do any additional investigating either.
- While you certainly might be benefitting from some of the properties that the original
cardrule is bringing in, you also might be clobbering it to that point at which you should be asking, why am I bringing in the rule at all?
You have two, much better ways to work with CSS frameworks that will be far nicer for your teammates, your future self, and the user of the app, who will get a more optimized experience.
- For the sake of clarity in the code. If you want to override a property or two in the framework’s class, create a new class and add it to the element after the original class.
- For the sake of loading less code, if your adjustments are going to be global, adjust the framework’s settings file and either use the SCSS in your project or build your own CSS with the custom variables that you put in.
6. Use a 12 Column Grid Unless You Have a Good Reason to Use Something Else
Both Bootstrap and Foundation give you these mixins that you can wrap into your SCSS rules that give you total flexibility when designing a grid – if that’s what you’re doing.
If you are not creating a grid that will be used consistently throughout a large project or a number of projects, the idea of defining ‘semantic’ styles with a customized grid in various places, can quickly turn into a nightmare.
I’ve worked on several projects where very similar table-like elements that coexisted in the same view operated in a different grid system. Oftentimes they were nested within one another. None of this was obvious from the markup and while the idea may have been to create semantic styles, the naming was far from it. The result was something like this…
A top level container uses a seven-column grid. The two left columns contain a grid with four columns, and the four right columns contain a six-columns. There is also a custom grid inside that. Below that, there is a very similar looking element, but this time it’s a ten-column grid. The selectors aren’t even named appropriately and all this customization is used in something like
Yeah, I know that sounds extreme, but this kind of stuff has left a bad taste for customizing grids when you don’t need to. Not only is it confusing to maintain, it’s actually bad visual design. When there no implied lines for the users’ eyes to follow, the whole application looks messier than it needs to.
A lot of smart people have agreed that 12 columns is a versatile standard to work with. You can nest grids inside of grids and get a little creative with proportions, but it’s still reasonably easy to trace column widths, when the column proportions don’t change on every level.
All that said, if you have a use case for a seven column grid and you can’t make it work with 12 columns, that’s what the mixins are there for. Solve your problem! Don’t let me stand in your way!
I think coding (styling included) can be quite difficult, and I believe that if you keep your code organized and consistent, you can worry about more interesting problems. Hopefully these thoughts are helpful to you, particularly if you’re working on forming your own opinions on the subject. If you have any opinions about anything in the article, please leave me a comment or connect with me on Twitter. I am happy talk about styling all day!