Categories
programming

Engineering CSS

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:

Header
some text

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.

Header
some text

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.