More Meaningful CSS

Tim Baxter wrote an article for A List Apart discussing the possibly dogmatic, and maybe unnecessary, use of classes for styling HTML elements.

Why do ‘.button’ when you can do ‘button’? Why do ‘.form’ when you can do ‘form’?

I think it’s important to understand the context of which class-based systems like OOCSS, SMACSS, and BEM have made their way into being.

With large, oft-changing web applications, there are certain problems that arise that don’t occur on simpler, less dynamic web sites.

My blog, for example, is a relatively straightforward site. I’ve made only minor revisions to the design over the last 7 years and my entire CSS weighs in an easily manageable 6 KB uncompressed.

There’s not a lot of complexity to the site design. I could use element selectors liberally. I could and have returned to that code after years of neglect and understand the code relatively quickly.

So then, why the need for classes on everything as advocated by myself and others?

These systems address the complexity of not only large projects and large teams but also of changing designs and changing code.

Back when I was at Shopify, we had inputs. Every project has inputs. They were styled using input selectors.

One of the problems we ran into was a redesigned input style that needed us to update the HTML structure around our input elements. Where this was especially problematic was trying to update the style and HTML across the entire application in stages.

Using input selectors meant that we needed to write extra CSS to undo the input styles to then be able to apply the CSS that we wanted via a class. We did this using a mixin to make it clear that this code was unwanted and that we could remove this mixin once the transition to the new style was complete.

When you have multiple teams working away on multiple branches, you can’t stop the presses so that you can apply site wide changes. Using element selectors inhibits the ability to make incremental changes to a project because you can’t be judicious with their use. Element selectors apply to all occurrences.

Another problem is that HTML5, while it introduces a number of new elements, does not go far enough to describe all of the unique components of a design. Nor do I think HTML ever will or ever should. (See Web Components.)

An element may also look different under different contexts. Not all navs look the same. Not all buttons look the same. Which requires you to concoct a selector for a specific context.

You can always come up with element selectors for a specific scenario, a specific combination of HTML. But large projects change and with those changes, requires the ability to decipher what the CSS is doing and under what conditions, in order to be able to change it at will. Otherwise, you end up with code you don’t understand and a reluctance to delete it or change it for fear something might break.

This is where class-based CSS systems like SMACSS excel. You can give something meaning with a name—a name that you and your team can decide together what it means.

With that class name comes a simplicity to your CSS. With a succinct grouping of classes, we begin to develop boundaries between objects on the page, like borders around a country. Each object has its own design and rules.

It’s no longer a single page, static in time. It’s a collection of pages, built with an array of components that change from page to page and change in design and composition over time.

A rigid system will break under the heavy winds of an ever-changing project. A flexible system will bend to your will, allowing your project to grow with greater ease.

Meaningful CSS is important. It’s also important to ask where and how we give it that meaning.