strazi.org is the design of kevin kennedy

Organizing Style

At the outset of a project, there is always that moment in time, as you create your first div and think to yourself, “what class name should I use?”

There are two primary schools of thought on this issue, semantic and presentational. The semantic school feels that the class name of an object should somehow reflect its purpose within the page. For example, if I were to create a poll item on my site, I might give it a class of “poll,” and then fill it with objects that have classes like “options” and “submit-button.”

Out of this methodology came further explorations where, instead of naming things based on their general purpose, a system could be used to help further aid in the organization of your classes. In the poll example, I might still start with a class of “poll” on the parent element, but inside I could have items like “poll-option” and “poll-button,” so instead of individual classes with no obvious relationship to each other, it is now clear that items related to the poll have a “poll-“ prefix to them in the code.

The nice thing about semantic naming, no matter the organization method used, is that your class names will make sense both to you and anybody else looking at your code. It’s unclear to me if there is any kind of actual accessibility gain, but it will make your CSS much more readable if you have to pick it up again after some time has passed.

In fact, let’s pretend six months has gone by now, and I want to add a signup block to my site. Semantically, I will just create a div with a class of “signup” and go from there. But what if I also want it to inherit all the base styling I already had for my poll? I could add the selector to my “poll” class definition, I could extend it with a preprocessor, or I could add a new class of “widget” to both items and pull out their shared styles into a separate rule. These are all completely valid options, but no matter what course you choose here, you will inevitably start to feel like you’re repeating yourself. For example, if I want a button in “signup” to look slightly different from the one I’m using in “poll” I will need to overwrite several rules or rewrite them them with slightly different values.

Wouldn’t it be nice if I could just define the object from a set of rules I had already created? This is the thinking with presentational naming. Classes are focused rules that define only a few characteristics of an item. To return to our poll example, instead of creating new classes to apply to the items, I can write something like “m10 bBlue f12” which would mean there is a margin of 10 pixels, a blue background and a font size of 12 pixels.

The classes are no longer connected to the function of an object, but only to its appearance or structure. This results in CSS that is potentially much more maintainable and compact because the rules are so simple and can be used much more broadly. It can also help new team members quickly build new blocks without needing to define anything, just pulling from the existing options.

The hard part of both of these systems is that often times as web designers, we will only be able to control certain parts of the markup. Most CMSs let the designer create a template wrapper, but much of the code that fills it will be generated by some other system using some other methodology.

The goal of each system is to avoid situations where, after a few years of working on a site, the CSS becomes a a tangled mess, and whenever you try to add anything to your site, you end up having to override and rewrite chunks of styles just to get your desired effect.

For my part, the idea of presentational CSS only makes sense up to a point. Having classes that are so closely connected to a single rule means that I might have to rewrite HTML constantly. For example, if I have a box with an “m10” class, but I want to change it to “m11,” that’s potentially a big change across every template. Whereas if it had a class of “box” I could just change it one place, because there is no inherent style associated with “box,” it is something that I define.

What got me thinking more about presentation, however, was clearfix. Clearfix doesn’t apply much visual styling, but it is something that I find myself adding to elements constantly. It is firmly on the presentational side of classing things because it adds no semantic meaning and applies solely to the structure of the document. Other examples would be situations where I just want to add a little bit of padding to the top of an element, or I want something to be red in a certain place. These are situations where I would find great value in classes like “pt10” or “red.”

The power we got with CSS was that we could style a document completely independently from the content. We were given powerful selectors to pick and choose what we could style. But with modern websites, our CSS is becoming nearly as complex as the structure itself. Our reaction to this was to create systems to help maintain styles as a site grows, so the CSS can grow in an orderly and maintainable way as well.

Today, the best path seems to be on a kind of middle ground, where meaning can remain, but utility classes focused on specific properties and can be sprinkled liberally throughout the codebase.

If the CSS styles were a library, one camp might have us divide all the books into their subject matters. The other would prefer to number each book, and then group them by that number. Alone, they both don’t work that well, but being able to group something by subject, and then fine tune it with a number? That sounds pretty good.