Don't fight the CSS cascade.
With tools like Sass and Compass, you can use partials to sort your CSS better than ever before, but you can also go horribly wrong:
CSS is built around the cascade, which takes into account both code order and selector specificity. Any sorting technique that is based around function rather than cascade is bound to cause conflicts.
If you try to sort by functions (layout, typography, style), you end up repeating selectors and creating new specificity wars. Instead, use the cascade itself to help you sort. Start general, then get specific:
1) Reset
2) Defaults
3) Helpers (clearfix, classes to @extend)
4) Page Layout (the shell)
5) Elements by type (classes)
6) Elements by module (IDs)
7) Overrides
and so on...
Written by Eric M Suzanne
Related protips
9 Responses
It's a great structure to follow, makes things so simple!
I was meaning to write about this, thanks for sharing :)
Hi Eric, caught one of your presentations at a Mpls AEA. Great work.
Another thing I notice A LOT in CSS PreProcessors is when developers abuse the nesting system and consequently have complex cascades as a result.
A great tip would be to avoid unnecessary nesting of CSS selections, and keep classes and IDs at the root of the cascade as much as possible.
For example:
.box {
}
.box-p {
}
- is far more maintainable than -
.box {
.box-p {
}
}
I push this a lot at my agency.
Hi Brad,
You're right. You also have me confused with the other Eric A. Meyer (meyerweb.com). Yes, there are two of us.
Cheers,
-e
Haha, did not see that coming. Thx.
This is how I usually end up structuring my larger projects: general to specific. I recently tried to split things up by color, typography, etc for a smaller project. It's untenable in the long term. We don't edit "just the colors" or "just the typography" when we're doing maintenance or feature-adds. We're "changing this component" or "adding a new component." When one thing is spread over multiple locations, you play hide and see with your declarations.
I usually end up splitting my sass into the following:
-variables and defaults (everything from colors and font families to grids and resets, not in that order)
-core (good defaults the the bulk of the project will use over and over)
-components (modular bits and bobs that go everywhere but are their own ecosystem of style)
-page specific (overrides on a per-page or other grouping mechanism basis)
You can also use some kind of compressor that find the same selectors and merge them into one block.
No. Compressing selectors goes directly against my point. Code order is an important part of the cascade. Order is meaningful. Letting a third-party tool adjust your code order based on nothing but selectors is a really bad idea, and could arbitrarily change the meaning of your code.
Any sorting technique that is based around function rather than cascade is bound to cause conflicts.
Meaning, you are not a proponent of SMACSS, BEM or Atomic at all?
Hauleth, I would never trust a compressor to re-arrange my cascade in ways I can't control.
Nerdfunk, Atomic is my favorite of those, and actually follows the cascade quite well. Both atomic design and the cascade move from general patterns towards more specific modules. SMACSS and BEM have a lot of good ideas (I often use naming conventions based on them), but it does seem like they're goal is to defeat the cascade rather than using it. No method is magic. Take what works for you, and leave the rest.
