How To Develop Scalable And Maintainable CSS

Posted: 02 Apr 2012 05:30 AM PDT

Last weekend I came across more ideas about our changing css best practices, specifically a presentation by Andy Hume and an article from Nicolas Gallagher, both of which offer additional thoughts to what I’ve been talking about these last few weeks.

I wanted to discuss each a little and more importantly point you to both in case you haven’t seen them. Some of you have also provided even more for me to take in on the subject and I promise I’ll get to those links as soon as I can.

Andy’s presentation, CSS For Grownups: Maturing Best Practices, (found via Jeremy Keith) builds on the work of Nicole Sullivan with OOCSS and Jonathan Snook with SMACSS.

His talk mainly looks at moving from current descendent selector practice toward a more modular class based approach. The presentation is a 50 minutes long and I recommend listening while following along with the slides, which I’ve also included at the bottom of this post.

Nicolas’ article, About HTML semantics and front-end architecture, is more focused on html semantics and dispels the notion that all these class names are unsemantic. If you’re struggling a little to move toward classes due to worries about making your html less semantic I think his post will convince you that you don’t need to be worried.

Why Rethink CSS Best Practices?

It’s relatively simple to learn the syntax and basic use of css. What’s not so simple is to create scalable and maintainable css systems. Many of the best practices we’ve developed over the years aren’t helping. If anything they’re leading us to develop less scalable and maintainable stylesheets.

This gets masked at times if you only work on smaller sites. With fewer instances of difficult to maintain code, you can usually overcome the maintenance problems with a little extra effort, but the issues are still there.

Even if you don’t currently work on large sites or plan to, you should still rethink best practices and improve your systems. Small sites grow larger. Personal goals change. New technologies and techniques spring up all the time and we should be prepared.

The main ideas behind all this rethinking of best practices is

To create us more maintainable css
To help our css coding practices scale

Let’s consider a couple of ways toward these goals, decoupling our html and css, and better choice of class names.

Decoupling HTML and CSS

Andy’s talk was in part about how we can uncouple css from html so our styles are less dependent on our structure. Less coupling leads to a more maintainable site. I mentioned this concept in my posts about OOCSS and SMACSS.

At first glance it seems like adding classes to html increases coupling due to the added markup, but the opposite is actually true. Coupling is increased the more dependent we are on a specific html structure. Jonathan Snook referred to this as the depth of applicability. The greater this depth, the greater our html and css are coupled.

Unfortunately our best practices the last few years have been increasing coupling even as we thought we were decreasing it.

Compare the images from Andy’s slides above this section and just below. In both the css is simple. It’s adding a background image to each of three different social buttons. In the slide above the selectors take the form .social li:nth-child(x).

When this nth-child selector is used, structure and style are highly coupled. Changing the order of the html so the Facebook button comes before the Twitter button requires a similar change in the css.

On the other hand the slide below shows similar css, except the nth-child selector has been replaced by a class in the form .social .twitter. This requires that extra code (the new class) be added to the html, but now you can rearrange the order of the buttons in the html without having to make any changes to the css. There’s less dependence on the specific html structure.

Later in the presentation Andy talks about different layers of css. He offers 4 in his example without suggesting these are the only 4.

Document
Base
Module
Layout

The concept should be familiar if you’ve looked through the SMACSS documentation. Andy’s idea is that a block of css should only affect one of these layers. He shows a variety of css styles and which layers they affect. For example:

 .promo-box {   color:red;   background: black; } /*  module only */ .promo-box h3 {   font-size:1.2em;   text-transform: uppercase } /* module and document collide */ .promo-box h3, .promo-box h4 {   font-size:1.2em;   text-transform: uppercase } /* continuing to add more document collisions */ .promo-box .promo-box-h {   font-size:1.2em;   text-transform: uppercase } /* module only with the second class expanding on the first */

The two blocks in the middle tie things to the html structure by including the hx tags. You can imagine how this can quickly get out of hand as you add more headings or other elements. The combination of the first and last blocks of css above are best. Each affects only one layer of the css, in this case the module layer, and it makes the resulting css much more manageable.

Andy continues with an example of headings alone. I’ll let you check the presentation and slides for the details, but the gist is he transforms the typical hx styling we do to a class based approach.

 h1 { font-size: 3.0em; } /* initial hx selector */ .h1 { font-size: 3.0em; } /* changed to a class named after the hx tag */ .h-headline { font-size: 3.0em; } /* changed to a class name that better describes it's purpose in the design */

He walks through lists in a similar fashion moving the css from ul.product-list li to .product-list li to .product-item.

Semantics and Class Names

One of the best practices the industry is trying to change is to avoid classitis at all costs. We’ve been taught that classes are unsemantic and we should add as few as we have to. This isn’t true.

Nicholas’ article focuses on class semantics. He says there are different types of semantics. We tend to think content driven semantics when talk about the subject, but there are also agreed upon global semantics such as microdata.

He makes 4 points about semantics.

Content-layer semantics are served by html elements and attributes
Class names impart little semantic information outside of agreed upon standards
The primary purpose of a class name is a hook for css or javascript
Class names should communicate useful information to developers

He tells us that class names (other than the agreed upon) offer no semantic information to machines by default, however when chosen well they do communicate useful information to developers and so have semantic value. Because of this class names are always semantic since they always carry some meaning with them.

 <div class="news">   <h2>News</h2>   news content </div>

The above class name is a bad choice because it adds no additional meaning we couldn’t get from the content itself. It also ties the class name to the content and so can’t change easily. For example it wouldn’t make sense to present recent comments inside of a div with a class name of news.

Once again coupling has been increased, reducing scale and maintainability.

Our goal should be to develop reusable components that can contain a range of content types. The most reusable components are those with class names independent of the content they hold. Nicholas talks further about how we can make css components more reusable and combinable.

Javascript specific class names — (js- prefix) can help reduce the risk that changes break Javascript
Single-class css pattern — styles get defined on multiple classes so only one class is needs to be added to the html
Multi-class css pattern — styles kept more modular and multiple classes are applied to the html (preferred approach)
Structured class names — naming patterns to make presentational relationships more understandable

I’m only pointing out a few highlights here and skipping much of the detail. If you’ve been hesitant to use more classes thinking they’ll make your html less semantic, I think the article will convince you otherwise as well as offering some good advice for how to go about naming your classes.

It’s definitely worth a read.

Summary

Most of us have been following the same set of best practices for years. I certainly have. Unfortunately many of those practices were based on incorrect assumptions about coupling and semantics.

We’ve been making our html, css, and even javascript less maintainable for years. We’re used to it and have found ways to work around the problem or we work mainly on sites small enough to hide some of the issues, but those issues are there nonetheless.

It’s time we question these flawed practices and those questions are leading us to ideas like OOCSS, SMACSS, and css preprocessors.

One last time let me encourage you to listen to Andy’s presentation and follow along with the slides as well as to read Nicholas’ article. I’ll get to the presentations and articles some of you have pointed me to as soon as I can.