Level Up Your CSS
At an internal technical presentation I did recently, a developer here at Mavenlink asked a great quesion: “What CSS resources are there for learning CSS best practices?”. Here are my current favorites:
If you’re really serious about getting the fundamentals of CSS and layout and willing to read a full book on it start with CSS Mastery. The second edition came out in late 2009, which is sort of the perfect time for a CSS basics book since it goes just a bit further back than we currently support here at Mavenlink, and provides a nice historical context for how things have evolved in the landscape.
Then I’d look at smacss smacss, which might take an hour or so to read.
For OOCSS, just see these two principles and ignore the disarray of other stuff out there: oocss principles
I generally like these two principles, although I must confess that I don’t always strictly follow “Separate structure and skin” since we now have things in Sass like placeholders that will allow you to abstract such things. So the idea is you’d take:
1 2 3 4 5 6
and split it out in to two classes: one for the skin and another for the structure. So the display and float would be in one def and the border and color in another. But, as I mentioned, I don’t think this is quite as much of an issue with Sass these days, and I’m not sure how crazy I’d go with this since it would add a ton of classes. If I did do this, I’d probably structure it like this:
1 2 3 4 5 6 7 8 9 10 11 12
Or, possibly consider using a
@mixin for this. Doesn’t it feel contrived though? It does to me, and so I’d state that you only need to do this when you’re seeing 3+ types of skinning rules creeping in to your module. It’s a matter of taste.
If you’re in to source code deep dives, you can look at a Buttons library that I coauthored. I would say that it’s most similar to OOCSS, and that was definitely an influence on the Buttons library.
What about BEM?
BEM is a popular newcomer to this area and great for really large projects as it enforces very strict naming conventions. However, I feel that its syntax is very distracting and I believe it’s essentially Hungarian Notation for CSS. So I’m not drinking that Kool-Aid quite yet, and I believe that you can manage fairly large projects with a combination of oocss and smacss (and just some good ole’ pragmatism).
But, but…I Hate to Read!
Ok, so you don’t want to click the above links and just want to see some examples. Here’s the crib sheet:
Use shallow selectors (also called Depth of Applicability)
So basically don’t do:
When you could just do:
- You can no longer use
.bazif it’s “nested” within
- It will save you from “specificity wars” later on
- Less work for browsers to parse (okay, that’s a bit of a stretch, but still true)
Oh, and while we’re using an ID in an example, just don’t do this in CSS if at all possible. It’s super specific and will cause you grief later down the road.
!important for state changes that are applied at run-time for “state rules”
For example, something like
is-collapsed can go ahead and use
!important since it will likely need to beat a more specific rule. See smacss state rules which states:
Since the state will likely need to override the style of a more complex rule set, the use of !important is allowed and, dare I say, recommended
Element Selectors are a “no-no”
OOCSS states separate container and content as in “rarely use location-dependent styles” and smacss just says plainly to avoid element selectors:
Now, if we end up with structure like the following we’re not screwed:
1 2 3 4
1 2 3 4
Another benefit is that I can now pull in
.module-heading elsewhere, should I need to. Also, performance will be better since, in the case of styling directly to the
h2 element, the browser will have to check for a
.module parent for EVERY
h2 it encounters! See the “CSS gets evaluated from right to left” section of this page.
This is related, but essentially, we’ll take code like this:
where the #sidebar case is perhaps a smaller version of a button that’s more appropriate for the sidebar, and change it to this:
button-small is a super-useful submodule. Now it can be used outside of the
#sidebar, which is a big win. We’ve also reduced specificity.
In trying to keep this brief, I’ve skipped over some areas such as dealing with things that aren’t modules (like pages or layouts), how to organize these, dealing with state changes, etc. (But the resources I’ve provided above don’t skimp; so go read them if you’re wanting more.) Otherwise, I think that you’ve seen that there’s some overlap between oocss and smacss and that the core principles are quite easy to grasp. Getting a whole team to apply these and even refactor a successful legacy codebase is a whole other thing… perhaps we’ll attempt to tackle those problems in future posts.