Design Centric And Layered CSS Files

Posted: 20 Feb 2012 05:30 AM PST

One of the ideas I always find myself coming back to is separating different aspects of design into layers. Typography on one layer, color on another, grids on yet another. By constraining all, but one layer, the unconstrained layer can be more deeply explored.

One way I think about this is how to best organize css files to take advantage of this layered approach to design. My thinking is a design centric approach to stylesheet organization would allow for better experimentation and learning and possibly make maintenance easier.

I’ve struggled in the past trying to implement (and perhaps explain) this idea and I suspect what I’m looking for lies in some recent css thought that I’ve yet to look into fully.

Revising flawed practices
OOCSS and SMACSS
CSS preprocessors

My aim with this post is to serve as an introduction into the above, from the perspective of this design centric css concept. It’s also here to push me a little into looking deeper into each of the 3 topics and to jot down some general thoughts and ideas.

Layered Design

The basic idea is relatively simple. It’s that we can learn, work on, or maintain, one aspect of design independently of others. Imagine you’re working on an existing design and you’d like to overhaul the color scheme. You should be able to work on this without having to make changes to the typography or underlying grid the site is built on.

This can be a great way to learn design. With so many different things to learn and practice and it’s impossible to tackle them all at once. The same way we set constraints before beginning a project we can set constraints on our learning and limit the design palettes we work with in order to experiment with fewer things at once.

Of course, for a design to be most effective it needs a sense of unity and harmony across all these layers. Picture one set of parallel planes, each representing a design layer, and another set of parallel planes representing things like unity and concept that cut across the first set of planes connecting them.

Typography
Layout/grid
Color
Imagery
General aesthetics
Content
Interaction/experience layer

There’s no question that the above work best when they work in harmony with each other. Any grid you create would naturally be based on something like type or image sizes. The point is that we could study grids better by holding to a fixed set of typographic characteristics or holding colors to grayscale while we explore different font choices and type characteristics.

A Design Centric and Layered Approach to CSS

I think most of us write css top down. We style the main header or masthead and work our way down the design through content areas and asides, until we reach the footer. We end up with our css organized around these large sections of our layout.

We probably also have sections for a base set of styles and another for common classes we use throughout our html, and perhaps a set of reset styles. The css for our main navigation bar is all in one place as is the css for your sidebar.

This approach is easy when developing as we code in the same order as we see elements in the design and it makes sense if your goal in maintenance is to rework your entire navigation to have all the navigation code located in one place.

There’s nothing wrong with the above, but I wonder is this how we can best maintain a site? Is it truly how we’d realign a design.

Isn’t it just as likely we’d want to change the entire color scheme of a site as we’d want to solely rework the navigation bar? Might we want to modify a site’s layout without altering the general aesthetics of buttons, and other design elements?

Lately I’ve found myself wanting to change something like the baseline grid for a design and with this top down approach the styles affecting the baseline are located throughout the entire file. It would be much easier if those styles were all located in one place or at least set up to be more easily changed.

For example take something like the following.

 #primary {   margin: 2em 12.5% 3em 0; }

Right and left margins are more aligned with layout. Top and bottom margins are more connected to a baseline grid. Now consider the above rewritten as

 /* -- placed in a layout section -- */ #primary {   margin-left: 2em;   margin-right: 0; } /* -- placed in a baseline subsection       within a general typography section -- */ #primary {   margin-top: 2em;   margin-bottom:3em; }

It’s certainly more code, but I wonder how much easier a set up like this would be when wanting to change only the baseline or only the layout.

Naturally whether or not this is easier to maintain depends on what you’re more likely to modify after the initial design is complete. Are you more likely to rework your footer without touching your header or are you more likely to change the color scheme affecting both while leaving the type intact. Of late I’ve begin to think it’s the latter more than the former.

There are a couple of problems I’ve encountered when trying to develop with this approach in mind.

It’s easier to develop initially with a top down approach.
It’s not always clear in advance what you’ll want to change, confusing how best to organize things.
Some styles seem appropriate in multiple sections.

With the first it could simply be a matter of being used to a certain way of developing. However, I get the feeling top down is generally easier to start with and that refactoring the code would become necessary to organize how I want. It’s an extra step though. With the latter two items it’s hard to know in advance what’s going to be better.

Where to Look Next

While I’ve been thinking about all this some new thought about css in general has gained prominence.

Revising flawed practices
OOCSS and SMACSS
CSS preprocessors

The idea of revising some flawed practices comes from Nicole Sullivan who’s suggested some of the things we hold as absolutes in the way we code shouldn’t be seen so absolutely. They were developed years ago under a different landscape and it’s time to rethink them.

OOCSS and SMACSS come out of this rethinking and are ways to develop more around reusable classes and to organize our css around these reusable classes.

I think in the end what I’m looking for will be found mainly in css preprocessors like Sass and Less. If you’ve been playing along as you’ve read this post, the thought of being able to use variables has possibly come across your mind once or twice. However I suspect the first two will also contribute to what I’m after.

In any event I’d like to explore each of the above topics in the coming weeks. If you’ve already looked more deeply than I have into any of them please share your thoughts, especially in regards to how they might fit into my design centric and layered approach to css files.