This is a beginning draft of a presentation on designing CSS, and best practices involved therein. My hope is to spread knowledge of good CSS practices, and continue discussion of concepts central to writing extensible, maintainable, and fast CSS. Yeah, a lot of this is discussed by Nicole Sullivan. Oh well.
Everybody uses CSS. It's just the way the web works. For developers, it makes our applications look pretty. For designers, it makes our designs concrete and usable. There's a problem, though: We rarely think about how our CSS itself is designed, and how that affects the speed, extensibility, and maintainability of whatever it is we're working on.
Developers who have the programming background to understand these concepts want to worry about the functionality of the application (CRUD, APIs, etc.). Designers want to worry about how the application looks and feels, rather than the structure of the code.
So, CSS is in this middle ground where developers don't want to think about it, and designers don't want to think about it, and it gets neglected. We end up with massive amouts of unmaintainable, inexensible, and potentially slow code.
Alright, so CSS isn't going to cause seconds-long delays in the load time of your page unless you're doing something terribly wrong (I'm looking at you, @font-face). But, in the words of Google, "The Internet should be fast", and the growth of the mobile market is actually decreasing the amount of bandwidth the average user has available. Wouldn't you rather use those precious bytes on some cool JavaScript functionality or another slick image? Yeah, me too.
But it has to be maintainable too. It has to be extensible, and readable, and all-around easy to work with. I don't want to have to spend hours writing CSS for a new page, or making changes to an old page. Nobody does. I'd much prefer to tell a client that a job will take 2 hours, and then complete it in 20 minutes (obviously only charging for the 20 minutes). Obviously, to achieve these ends, we must identify various patterns and determine which ones promote these goals, and which ones don't.
The problem is that there hasn't been a lot of talk about CSS methodology. There's plenty of chatter about particular solutions and techniques, and about cool CSS3 stuff, but it's all about how to accomplish tasks with CSS, rather than how to accomplish the task of writing good CSS. Boilerplates and frameworks have emerged to help with the task of writing CSS, but often with an eye toward making browsers behave or making CSS easy for designers (or, to take it further, to turn CSS into a design tool).
There are a few principles I follow when thinking about my CSS:
- DRY
- Container vs. Content
- YAGNI
Let's take a look at DRY - Don't Repeat Yourself. This is a common concept in programming. Simply put: don't write your code more than once. Don't copy/paste/tweak. Algorithms can often be made generic, and they often are when we're writing code for functionality. But visual elements can be thought of as generic as well.
Let's take a look at a pretty popular site: wired.com
Wired has a lot of repeated elements on the home page. Okay, so they're not exact clones of each other, but they're very very similar. In fact, they're what Nicole Sullivan would call a media element, but specialized to fit Wired's needs. It consists of a category, a title, and some details, with an image to the left of it.
Honestly, Wired's code is kind of hard to follow. There's a lot of it, and it uses a lot of IDs. Not best practice (and a great example of the "get the job done" mentality when writing CSS). If it were me, stealing Stubbornella's terminology, and coding for Wired, I'd write it like this:
.media img { float: left; margin-right: 1em; }
.category { font-size: .6em; color: #007CA5; text-transform: capitalize; }
.details { font-style: italic; font-size: .6em; color: #999; }
.above-the-fold { font-size: 1.8em; }
.below-the-fold { font-size: 1.4em; }
Now, if we were to combine this with my CSS positioning boilerplate (and some well-chosen heading sizes), we could write some simple HTML that would closely replicate Wired's article layout:
[code]
And not only that, but we can use any of these styles in other parts of our site. They're not tied to this particular kind of element, and they're not tied to layout.
This promotes a holistic approach to CSS. In order to write DRY code, you have to identify the common elements across your entire site, and write code that represents those in a modular way. And when I say "elements", I don't mean HTML elements. I mean design elements. A particular repeated pattern. These are easiest to identify in headings, links, headers, and footers. But The more abstract elements may be tougher to find. An entire blog post may be a media element, if your posts have an image on the left and your text on the right. Maybe you have code on the left and its explanation on the right. We could easily modify the media element to handle that (as well as images, videos, etc.)
Now, designers, you're probably going to hate me for this, but I'd like to posit that if something doesn't fit in to your "object structure" - the repeated elements on the site, then you probably want to question why it doesn't fit. In other words, if you're writing CSS specifically for a certain element, you're probably doing it wrong. It could fit in to what you already have, and could thus be written with HTML (without having to touch your CSS), or it might end up being an honestly unique part of your site.
Next Up: Separation of Container and Content.
Your layout should be one thing. Your looks should be another. That's the gist here. This separation makes it really easy to change the layout without affecting the looks, and change the looks without affecting the layout. It's most easily demonstrated by example.