Structure and Organization of CSS

A few people have asked me how to keep their cascading style sheets under control. This isn't a question related to LESS and SASS, although both of them can help build maintainable styles, but more of a question about how to keep a team from hacking a stylesheet until it grows to rival the complexity of the United States tax code.

Here are a few thoughts.

1) Try A Framework

Even if you don't use a framework in your product, you can learn from one, and borrow ideas. Over the last couple years I've worked with Bootstrap and 960gs, as well as the CSS themes provided by jQuery UI and jQuery Mobile. I'd consider Bootstrap and 960gs to be more along the lines of "full" frameworks because they cover everything including resets, layout and typography for an entire application. jQuery UI's CSS leans more towards working in the background to support UI widgets, while jQM is a bit of both.

Regardless of which framework you look at, you'll see how they define well-factored, reusable  classes. For example, a vertical navigation bar is something you build with Bootstrap by applying three classes:

<ul class="nav nav-pills nav-stacked">
    <li class="active">Home</li>
    <li>About</li>
</ul>

 

Although they could provide a single class definition to achieve the same effect, the single class would be harder to reuse for other scenarios. It's almost as if the style definitions in these frameworks follow a single responsibility principle. A header bar in a jQM application uses two class definitions: one to make a header and one to make a bar.

<div class="ui-header ui-bar-f" data-role="header">
 ...        
</div>

 

Having generic, reusable styles means you can combine styles together to create new things instead of inventing new styles, which leads to #2.

2) Use Conventions + Selectors

For some projects the number of distinct classes you can find in a stylesheet is overwhelming. It's easier for developers to create new styles than try to figure out how to use the existing styles. Part of the problem here goes back to #1 and the single responsibilities, but part of the problem is the combination of each developer writing unique markup and not using what CSS selectors can offer.

For example, consider the following markup using 3 different classes:

<div class="product">                    
    <hgroup>
       <h3 class="productTitle">@product.Name</h3>  
       <h4 class="productSubtitle">@product.Subtitle</h4>                                                             
    </hgroup>  
    ...
</div>

 

Let's change the CSS around so only a single class is required, and only on the top level element.

.product {
    background-color: blanchedalmond;    
}    

.product hgroup > h3 {
    background-color: darkmagenta;
    ...    
}

.product hgroup > h4 {
   color: black;
    ...    
}

Fewer named styles mean there are fewer concepts to grasp when learning how to use the styles.

3) Someone Has To Care

When I work on a project with a dedicated designer there is rarely a problem with stylesheets. It's not that the designer has a fantastic knowledge of CSS (they usually do), but just having someone who cares about the structure and organization of the CSS helps keep it in shape.

It's the large projects with no designer where the CSS grows unwieldy, because styles are a low priority item. It only takes one person who cares enough and monitors the use of styles to bring up issues early before the issues turn into problems.

Other thoughts?