A Better Way for Organizing CSS

There’s been quite a lot of talk in the Web design community regarding the organization of long, unruly stylesheets. Good points have been made by most of CSS’s talking heads, with Douglas Bowman’s Stopdesign article receiving the most link-worthy praise: see CSS Organization Tip 1: Flags.

Honestly, as it is no longer 2003, or 2005, or whatever year you consider to be the latent awakening of popular CSS usage, these rules of organization - moreover these helpful tips – can largely be considered givens rather than guidelines for any serious designer.

Please don’t mistake this entry for animosity, as I must admit, there are a few good closet-cleaning guides that delve a little deeper than saying “use flags to structure your CSS document.” However, the revelations these articles espouse are little more than “be sure to indent children selectors” and “it’s a good idea to use CSS shorthand.”

Come on. Really?

Is that the best advice (and subjective advice, at that) that there is to offer those few remaining designers who are just getting their feet wet with proper declarative markup?

Rather than spout off some relativistic heuristic for organizing the structure of the entirety of my stylesheets, I intend to rather explain my methodology for writing meaningful, on-the-fly value declarations that I give to my CSS properties. So instead of telling you the “how” - because honestly, your “how” may be very different from my “how - I’m going to show you my “why”, and how it came to be from the theory of the CSS box and block models themselves, or as I like to romanticize, from a rather ill-remembered junior high school extracurricular activity.

Visualize-It, Declare-It

Back in junior high and for a brief stint at the end of high school, I was a member of Science Olympiads. If you’re not familiar with Science Olympiads, well, it doesn’t really matter, just think of it as a geeky track and field meet, with events like “Mission: Possible” (small scale Rube Goldberg engineering) instead of, say, the 100m hurdles. Got it? Good.

One event in particular was called “Write It, Do it” and as aptly entitled you would write it and then proceed to do it.

Specifically speaking, one member of your two person team would write about a mystery object – describe it as best as possible within a given amount of time - and then based upon this lengthy and hopefully very telling description, the other member of the team would begin, to the best of their ability, reconstruct that said mystery object. The results of this event are largely rooted in a team’s capacity to both mentally visualize and physically design.

The same can be said for CSS, when it is you, the designer, who are responsible for taking HTML code and transposing it into beautiful on-screen presentation. If you also happen to script the HTML, make it easy on yourself by writing with a standardized approach, giving lots of semantic meaning to your ids and class names.

For you are the “team” in this instance - both visualizer and presentation declarer.

The Greater Application to CSS

With that said, let’s get down to the grit. If you have a line of code (and yes, you’ll have lots of them) that needs a presentational declaration, think to yourself: how would I sequentially describe this [insert selector here]?

By handling your HTML/CSS infusion in this way you can begin to visually morph a simple line of code, property by property, until you end up with your desired result. I like to think of it as taking a small blob of Play-Doh and continuously morphing it until you get your Doh-thing. And very similar to yet altogether different than Play-Doh, CSS goes through its typical, sequential stages until an element’s style is thoroughly defined. So as a blob of Play-Doh first and foremost goes from rolled-out tube to exquisite, whimsical, thumb-printed daisy, it’s rather easy to visualize your decorative call-out if you prioritize the order in which you add value to its properties.

For me, declaring the display property is of utmost importance for visualizing what my end-result will be. Granted, keep in mind which properties already inherit their correct display from whatever base stylesheet or reset you’re working from. Once you have the display nailed down, you can whittle out the remaining intricacies of your selector.

While I like the go after the display and the positioning of selectors, followed by margins, padding and any other outer-bounding properties, I urge you to use your own philosophy of visualization when designing.

If I were to hold up any given LEGO block, which property of that block would describe it best so that you would be able to find the most preferred placement of this block on any given LEGO board? Color? The decorative sticker-label on its front?… It’s shape? Size?

Exactly.

Ordering my properties as I design is of much more importance than structuring my stylesheet as a whole. I typically work sequentially down the page, so I feel that I’ll clean up the ordering of entire groups of selectors after the document is formed. However, it is imperative that during the design process I have the ability to easily sort through the individual properties and values themselves. For this reason, I prioritize my CSS properties based upon the sequential steps of my mental visualization.

I have seen people that alphabetize properties, and this to me, is utterly confusing. I would much rather a preferred, ordinate sequence of “building” than a linguistic-relative list.

While I urge no person to follow my methods explicitly, I do demand that you feel comfortable in your design element. For me, it is beneficial, for both my time spent at work and for my mental clarity, to order my CSS properties as I declare - creating easy recall and identification during an often volatile design process.