With sites becoming increasingly “full” with the focus on design, regardless of the simplicity, the explosion of CSS and it’s management is burdensome. There are some tools; some processes, but working with CSS on a “code level” has still got a long way to go. Yes, there’s SASS, which can help, but you’re still dealing with a myriad of artifacts. Let’s look at a simple block, for example:
There are 3 basic elements involved: a container block, a header and a body. This is just one block with 3 different CSS declarations. On a simple site, that’s only 3 artifacts you need to:
* name
* code
* maintain
* version control
* test
Scale that effort across a decently-sized site/project and you quickly end up with an insurmountable number of artifacts. And one of the biggest challenges facing just about every programmer is coming up with names!
Name for a library. Name for a class. Name for a method. Name for a variable. Name for a stored procedure. Name for a table. Name for a view. Name for a controller. Name for a document. Name for style. In code, it can be relatively easy since it’s all function-based. CSS is a little different.
Sometimes you name it according to function, but you can’t always recognize it that way as a reference point (later on in time). For example: the function of the block above might be something quite general: “information-block”. But later on the same site, you have a similar function “information-block” that looks different.
It’s subtle. But different. So you try “light-header-information-block” and “dark-header-information-block”. Ugh. It’s getting bad, so you go with abbreviations: “lthdr-info”, “dkhdr-info”. Ugh. Worse. Maintenance nightmare. So you try a different strategy, name things according to area: “new-info-block”, “forums-info-block”. That gets wieldy, so you break up the CSS files into: news.css, forums.css, assessments.css. Inside there, you have an “info-block” definition and then just make sure you only pull in the relevant stylesheet. Meh.
Then you get those general, across-the-site-but-not-always, styles. It’s not easy. Then you throw IE into the mix or vendor-specifics and.. well.. your 3 artifacts just got trickier. And then let 2 or more front-end guys loose on the same site with their own thinking and logic…
Ok. So while I don’t have a silver bullet here, I do have some strategies for dealing with the pain efficiently (as might be). Some already mentioned. Another is in the naming of sub-elements. As a guideline, I only focus on naming the bigger containing elements.
So, .info-block-wrapper { } for example. The nested elements we can always derive.
.info-block-wrapper .header {} or
.info-block-wrapper .body {} are easy. Even:
.info-block-wrapper div.header {} Or just:
.info-block-wrapper div {} where applicable.
Problem is using class=”header” and class=”body” is going to cause some issues just because they are such general names. So I prefix general names with the beloved underscore. Meh. _header and _body. As a co-operative to that guideline, I *never* define a _class style on it’s own. It’ll always be as a nested definition:
.info-block-wrapper _header {}
never
_header {}
This helps maintain some level of sanity while navigating through thousands of ephemeral definitions (yes, designs iterate way more than functional code) over the lifetime of a project with potentially as many front-end workers.
And then of course, there’s also the performance of CSS to consider. In terms of engineering, yes, CSS still has a way to mature while it also has the responsibility of being the most noticeable deliverable: a double edged sword if there ever was.