gu8npa
Last Updated: February 25, 2016
·
7.192K
· ericam
Mia 6

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...

Say Thanks
Respond

9 Responses
Add your response

230

It's a great structure to follow, makes things so simple!

I was meaning to write about this, thanks for sharing :)

over 1 year ago ·
317
D3fe491fd07d1bbce780696b3c468f4c

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.

over 1 year ago ·
318
Mia 6

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

over 1 year ago ·
380
D3fe491fd07d1bbce780696b3c468f4c

Haha, did not see that coming. Thx.

over 1 year ago ·
2430
150 twitter

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)

over 1 year ago ·
4954
Me

You can also use some kind of compressor that find the same selectors and merge them into one block.

over 1 year ago ·
4956
Mia 6

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.

over 1 year ago ·
14292
Radar normal

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?

over 1 year ago ·
14294
Mia 6

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.

over 1 year ago ·