Change my mind: CSS is hard. In fact, I preach day in and day out that scalable CSS is one of the more difficult concepts to grasp effectively. Here are 7 tips to help you scale and manage CSS and its alternatives.
To be able to scale styling effectively, you need to first think of the grander picture.
No amount of styling finesse will help you if your application cannot scale.
An example to provide here is the popular concept of Atomic design. While it is not the only paradigm out there, it is a great example into how you can think about how the parts of your application come together.
Atomic design is inspired by chemistry and attempts to take things from first principles. From this, Brad has broken down designs into five parts:
While this post is not a deep dive into that thinking framework (nor others), identifying and isolating smaller components from larger ones such as the pages will go a long way into how you begin to organize your style files and avoid repetitiveness.
Simple concepts like nesting in Sass and Less can make a world of difference to ensure your styles don't "bleed" into other style rules unintentionally.
For example, take the following trivial example:
What happens if we add the follow stylesheet?
What naturally follows are two
.container divs with a black background. Trivial? Yes. A troublesome reality? Also yes.
What happens if this is unintentional? While the example itself is trivial, what happens in a large scale app if your class name matches that in another part of the website? Unintentional side-effects, that's what.
Even the basics of nesting can help you prevent this:
As for tools like Post-CSS, it enables you to harness popular plugins such as the autoprefixer which enables you to forget about vendor prefixes altogether. You can see from their base example on the site how powerful this utility can be:
After processing with the autoprefixer:
As you can see, we no longer have to write rules for variant of browser - a most troublesome foe indeed.
Cool - so we've managed to save ourselves some code and are preventing some side-effects with the basic capabilities of pre-processors, but we are still in a bit of a pickle. We can still abuse these powers and end up in a mess. So what can we do next?
There are a number of paradigms, naming conventions and ordering tips that can help make traversing stylesheets easier. Here is a list of a few:
BEM is a popular style of class naming convention that is approachable and helps you understand the purpose of a class from first-glance. This is an introduction from their home page of this application in action:
The idea is that from seeing the
button is the block, the
state is the modifier and the variant (success/danger) is the
value which leads the convention to
block--modifier-value. There are a number of different preferences for implementing BEM based on preference ie
block--modifier__value is another popular approach.
For me, this is an incredibly underrated helper. Outside-in is simply a way to describe ordering your CSS within the block scopes.
From the article, it aims to order CSS properties in the following order:
Take the following example without this in mind:
Now compare it to a block that takes this convention onboard:
For such a simple concept, the latter block becomes far more approachable and is a small win for developer experience when those properties are grouped into relatable properties.
All three of these libraries serve as great guides and approaches to styles.
Websites such as RSCSS also provide great examples of common pitfalls that developers come across.
With OOCSS, it brings in the common programming paradigm to think object-first to help with re-useability and composition of styles.
SMACSS itself self-proclaims to be more of a style guide than a framework, so placing it in this section may be incorrect, but it certainly leads us to the next important point.
The beauty about web development is that web developers are the first to create amazing resources for their peers to use! You do not need to ~re-invert the wheel~ make the same mistakes as our predecessors.
Style guides operate as a great resource for helping decide upon the rules and conventions that you as a team wish to use.
Linters can help enforce coding conventions decided upon by the team. This helps enforce rules into the codebase and is a great help for new team members onboarding into the codebase.
Code formatters can bridge the above two and help re-format your stylesheets automatically.
Here is a non-exhaustive list to kick start your research into this:
While this starts to verge outside of the style specific territory, frameworks such as ReactJS in tandem with bundlers such as Webpack allow us to compartmentalize our styles so that they do not affect others.
For a very trivial example, let's take two components
Thanks to the separation and power of transpilers, the styling applied to both classes can be independent of each other and do not clash. This solves our previous issue around "style bleeding".
CSS-in-JS has been a relatively recent technology brought into the web development world.
I say recent, but even two months can feel like an era.
For those who want to harness these powers but still prefer the final CSS output, checkout alternatives such as Treat which enable you to do this.
This should be self-explanatory, but I have two requests:
// HACK: my reasonunless you are playing a prank on some poor developer inheriting your database two years later or you have a very, very good reason to do so.
Comments are powerful for humanizing the code and explaining what is happening in understandable terms. They are not an alibi.
These have been seven tips that I have learned along the way to help with my mortal enemy: CSS.
Here is to hoping that these resources help you in your own battle against maintaining styles!
Do you have any other tips that you have learned along the way? Share them below!
Image credit: Jerry Wang