CSS has been with us since the before time, in the long, long ago…
According to wikipedia, CSS was introduced in 1996, just shortly after HTML and the World Wide Web made their grand entrance on the stage of history. — — Making CSS a 23 y/o language, and one of the oldest technologies of the web that is still with us to this day!
Regardless of whether you are writing vanilla CSS for styling a landing page, or using full-blown styled-components in a full-stack React application, there may be a question that lingers in the back of our minds: am I doing this right…?
So here are 8 tips to boost your CSS skills and hopefully make the developers around you a bit happier.
I write this also for the beginner in mind, but I think these tips can help even those who have been working with CSS for many years.
1) Learn the rules of the road
If you don’t know what a stop sign looks like, it would be pretty hard to know when to stop, right?
The same is true for coding: it can be damn-near impossible to know if you’re doing something problematic if you don’t know what rules exist.
A good place to learn some of these rules or best practices about CSS quickly is to look at CSS rule definitions defined in linter tools like sass-lint.
Although the library isn’t maintained anymore, the definitions in sass-lintare classics. They represent best practices in CSS development that evolved from discussions among developers, which means of course that there is a good reason behind following each of these rules:
You might say, what difference does it really make if one writes border: 0 as opposed to border: none? And maybe you’re right…
But while each of these rules on their own may not seem very consequential, taken as a whole, following these kinds of best practices will help you write consistent code that is professional-level. And other developers will notice that.
2) Follow a styleguide (or make your own)
Like the linter rules above, a coding styleguide is a set of best practices that you choose to follow to improve your coding standards. The nice part about this is that the individual rules are organized into a unified system, so there is more coherence to it.
If you end up breaking a rule, it’s not the end of the world by any means — but if you do follow it, again, your code will take on a more professional quality.
Don’t know where to start? Then check out Airbnb’s “CSS / Sass Styleguide”:
They humbly call this “A mostly reasonable approach to CSS and Sass”. What’s not to love with something so charming and on-brand as this?
A bonus tip is to try to make a styleguide of your own based on the above example. You will inevitably learn even more about CSS best practices and you will have something interesting to talk about during frontend interviews.
3) Learn about specificity and keep it low
Specificity is all about how specific your CSS selector is. Let’s check a quick example. Of the following, which would you say is the most specific?
a {
color: blue;
}a.link {
color: pink;
}a.link.that-link.that-one-right-there.no-really-that-one-on-the-left.right-there.can-you-see-it.there {
color: purple;
}
Do you get my point? 😂 If only we wrote class names like this all the time we’d always know what we’re talking about, right?
Well, although not really practical it certainly illustrates better what is going on when we apply selectors and class names: the more selectors we use (and the type we use) changes how specific our style rules are for elements that have all of those selectors.
The more complex these selectors become, the harder they are to override. So try to follow these general guidelines:
- Use classnames and use few of them
- Only use ids for styling if you really have to
- Almost never use the
!importanttag (again unless you really have to)
That way, when you go to style something, you always know that you’re only one or two class names away from overriding that style.
It can be a little tricky at first, but once you get the hang of it, you’ll see the overwhelming benefits of keeping specificity low.
For more information about how specificity is calculated, check out these links:
4) Keep your HTML and CSS decoupled
It is very common to find css that looks like this:
div.main-wrapper {}
button.primary-button {}Okay, but what if your <div> changes to a <section> and your <button> changes to a <a> ?
Do you do this:
div.main-wrapper,
section.main-wrapper {}button.primary-button,
a.primary-button {}
Multiply that by 3 or 4 more tag selectors and you see that we have a problem.
CSS that is tied directly to an HTML tag is called “brittle CSS” because it’s hard to maintain and easy to break.
If instead you rely on classes alone to style your components, you not only keep specificity low, but you also ensure that your HTML can change without breaking your CSS.
5) Keep your CSS and JS decoupled
Not really applicable if you are using React, or another frontend framework of the sort, but the same thing as with HTML: if you have a CSS class that is also used in your JS, there is potential for problems down the road.
If you change the class name while editing the CSS, now your JavaScript is broken.
To avoid this, you can follow this 1 simple rule:
never use a CSS class for JavaScript if it is used for styling (and vice-versa)
How to avoid this? Easy. Create a naming convention for classes or ids that are connected to JavaScript so it is impossible to miss.
One common approach is adding a prefix for classes or ids that are connected to JavaScript:
<div id="js-app" class="app-wrapper">
<button class="js-add-user primary-button">Click me</button>
</div>See how easy it is to tell which classes are CSS and JS related?
6) Use a system like BEM or OOCSS
BEM stands for the “Block Element Modifier”, whereas OOCSS stands for “Object Oriented CSS”. Both represent different methodologies for composing id and class names in CSS.
Of the two, I think people are more familiar with OOCSS because it is the kind of class/id naming system that Bootstrap follows, for example. Let’s take a quick look at each of these and compare.
Say you wanted to create a modal. What would the class names look like?
If you wrote the styles in BEM, it might look like this:
.modal
.modal__title
.modal__title--large
.modal__bodyWhereas if you wrote them using OOCSS, it might look like this:
.modal
.modal-title
.modal-title.large
.modal-bodyThe subtle differences between the syntax here hides a lot about the schools of thought they represent, so if this seems like something interesting to you, by all means, please check out the following links:
Note: these systems are especially useful if you are writing vanilla CSS or Sass. If you are writing React without styled-components, see what AirBnB’s CSS styleguide has to say: https://github.com/airbnb/css#oocss-and-bem
7) Practice mobile-first styling
This will keep your code simpler and allow you to spot duplicate styles faster.
Instead of doing this:
.modal {
...
// a bunch of styles
}@media only screen and (max-width: 576px) {
.modal {
...
// styles for mobile specifically
}
}
Do the opposite:
.modal {
...
// baseline styles that apply for mobile and up
}@media only screen and (min-width: 768px) {
.modal {
// minimum override styles that are needed for above mobile
}
}
This allows you to make use of the cascading effect of CSS.
And because you are overriding only the styles you need above mobile, you can most likely write less code.
8) Use sass or styled-components
Okay, funny story, you want to improve your CSS and I say, use another technology. LOL.
Well, the reason we have these kinds of other technologies is because CSS is unwieldily if used alone, as you’ll certainly soon find out.
Sure, CSS gave us the ability to style HTML, but it also gave us super long files that not even god in the heavens above could hope to maintain.
Sass and styled-components solve a number of problems with CSS each in their own way, but one thing that both of them share is the ability to keep stylesheets short and to the point.
You will still be able to apply all the tips I describe above, plus you will be able to write code that is easier to read and maintain.
Conclusion
So many tips, so little time!
CSS has gone though many iterations — from plain old Cascading Style Sheets in HTML documents, to LESS/SASS/SCSS pre-processors, to CSS modules and CSS-in-JS solutions like JSS.
Despite the changes and the revisions from CSS to CSS3 (with CSS4 on the way?) the essentials of the language have remained largely in tact.
Best practices evolve from discussions among developers in the field to solve real problems that pop up over the years, so following them can help you avoid those same problems and thus make your code better.
Ultimately, you decide which coding practices you’d like to follow. But using these tips as a guide will certainly help you on your quest to conquer CSS or any language you want to learn.
The links and resources will change, but you can apply the very same methodology described above to up your game in any language you want to learn.
Like what you read? Please clap and comment below about what practices you like to follow.
