Thoughts on scalable, maintainable CSS

April 4, 2016


https://twitter.com/mrmrs_/status/713314317890879488

This post is heavily inspired by the article referenced in the above tweet. If you haven't already read it, stop what you're doing and go read it. Every once in a while you come across a post that challenges your assumptions and makes you take a step back and evaluate your process.

I know a little bit about maintaining large CSS code bases. At my current job, we have a 140 site network of Drupal 7 sites for the college. We also have a few WordPress installs and some other sites and static pages in the mix.

Maintainability is something I strive for. There are also some issues with maintaining CSS for large sites that haven't been addressed until now.

With all the different naming conventions out there, you'd think we'd have nailed it by now. The truth is, CSS is still a mess.

Preprocessors and build tools have brought us a long way, but what if that is the wrong place to focus?

What if you could open up your text editor and build the interface you want without writing a single line of new CSS?

could open up Sublime Text and write some fancy mixins and Sass functions that really are clever and then make some new classes for my components, but why? Chances are I've written CSS that does all of those things already.

I’m not very interested in what I can do with css. I’m interested at this point in what I can help groups of people do with css. -mrmrs

This brings me to why I'm so interested in the concept of one class, one function.

When working with a giant network of sites with distributed authorship, you learn real quick that you can almost never come up with a solution that everyone will like. Certain groups want slight variations to components that you built. Things come up.

What if we threw a bunch of lego bricks at them and said "Here's all the tools you need"?

Consider the following HTML:

<div class="card card--red"> 
<h2 class="card--headline">Headline</h2>
<p class="intro">Here is some test text</p>
</div>

Without looking at the CSS for this, can you imagine what it would look like? I'm guessing you would know it looks something like a card and maybe it has a red background? Other than that, it would be difficult to tell what is happening here. Are there any clues about fonts, padding, borders, or text styling?

Now, consider this HTML:

<div class="bg-red padding-2rem border-1px"> 
<h2 class="sentinel italic font-large">Headline</h2>
<p class="whitney drop-cap">Here is some test text</p>
</div>

You'll notice a couple differences right off the bat. There are more CSS classes, yes. But you can also get a much better idea of what the HTML will do. It is semantically clear.

Benefits of this approach include rapid interface development without having to write a line of CSS. Once you come up with all your "utility" classes, you're free to construct your interface using classnames in HTML.

Also, it allows a broader group of people to benefit from your CSS. People who may not be comfortable with CSS can now in plain English, add classes to their markup which does one thing without having to worry about side effects.

Let me be clear: I don't think this is a substitute for writing some abstract classes. I think there is still a need to write classnames that don't map directly to a function (ex: .header-top, .footer, etc) but the point is that a majority of the CSS functionality will be easily exposed in the form of plain English utility classes.

I think this has the potential to help large sites with lots of CSS and lots of people who use the CSS. I'm interested in giving this a try at my organization. When I do, I will most certainly report back here with my findings.

Check out the followup to this piece.