What follows is an incomplete philosophical approach to formatting CSS in a logical manner. I decided to finally post it after letting it languish after six years.

CSS Discipline: The Way Of Declaration Order

When working solo, it is easy enough to write your CSS in any manner that suits you. Naming conventions and style sheet structure are yours to command. There is nothing to worry about, as long as your mark-up validates and presents the page in a pleasing manner across compliant browsers. Who cares if your class names resemble abbreviations used for the Periodic Table of Elements and definitions for the header are a jumbled mess of properties in no particular order? As long as you can understand it, that’s all that matters, right?

The answer is, of course, wrong. CSS philosophers will tell you to use meaningful naming conventions for your class and ID selectors. They will go on to say that a style sheet should be organized with the framework or general elements of your website defined first; working down to the specific objects on your page. Inheritance by nature dictates the order in which we define our CSS. And when working in a collaborative environment, it is absolutely imperative that one developer be able to read another developers work and make sense of it all. This leads us to standardization, and standardization makes everyone happy. Standardization keeps us from tearing our hair out while trying to figure out what someone else has cooked up in their time with the style sheet, simply because we would all then speak the same relative language.

Enter the need for not only structure, but syntax as well. It is not enough to be conscious of how our style sheets are laid out. We need to also be aware of the declarations within our property definitions. In order for our CSS to be truly meaningful, the declarations should follow a standard method of formatting, a specific order of properties, and an understood method of shorthand. Formatting and shorthand are best left to the development team to decide which is best. Breaking lines, entering white space, and contracting long property declarations are exercises in visual readability, as well as methods for controlling style sheet file size. It is the declaration order which can further impact the true usability of your style sheet by multiple authors.

Declarations are, as W3.org tells us, “the part within the curly braces” of a style rule. A declaration is made up of two items: the property and the value of the property. There are well over 100 different properties that we could define for any given element. It is the nature of the functions of the properties that give the properties their importance. The properties of width and height will define the dimensions of an element, while the counter-increment property will generate content to be displayed when the page is rendered.

When we define our element declarations, we could literally start anywhere, with any property. Officially, style sheets do not require specific formatting when it comes to the order of the declarations contained “in the curly braces”. Some hacks will use escape characters to exploit browser rendering bugs, however those hacks usually involve repetition of the same declaration in a specific order, and are generally best implemented in a separate style sheet all together. As a whole, declaration order is not a technical requirement. It should, however, be a practiced requirement.

Hey You Kids! Get Offa Mah Property!

Content to come…

CSS Declaration Hierarchy: From Light to Dark

In defining an element, we should follow the age-old process of working from large, to small; from general to specific. In art classes, we were taught to work from light to dark; from blocking in patches of color and shades to fine lines and details; capture the entire scene first and then build up to the individual objects. The same applies to the structure of our CSS declarations as we define an element. In fact it makes even more sense, as we often only need the basic general declarations set, if at all.

The hierarchy of declarations begin with the most general description of the object and move inward and can include items contained within the object:
Classification Properties > Z Positioning (stacking order) > X/Y Positioning > Dimensions > X/Y Offset (container and content) > Decoration (box properties) > Contained Content Font Properties > Contained Content Decoration, Generated Content

Classification Properties
display, white-space, list-style, visibility, overflow

Z Positioning/Stack Order
z-index

X/Y Positioning
absolute, fixed, relative, float

Dimensions
width, height

X/Y Offset
margin, padding, clear

Box Decoration
background color, background image, border

Contained Content Font Properties
alignment, size, line-height, etc

Contained Content Decoration
weight, style

Generated Content
content, counter-increment, counter-reset

We may not always define a particular property, but instead we might allow for the inheritance to define the property. Even still we should follow the hierarchical order when listing the properties we do wish to define. For example, a single column container display would be written as such:

#columnPrimary {
    position: relative;
    width: 532px;
    margin: 0 214px;
    padding: 0;
    background-color: #FFF;
    text-align: left;
    }

Here I have followed the hierarchy defined the column with its positioning first (leaving the z-index to its inherited defualt), the dimension of width (height is left as default), the offset of margin and padding next, a background color and then finally the alignment of the content within.

This is, of course, a conversation starter. I haven’t been able to find other discussions on this topic on the web.

And here ended my grand plan. With the introduction of CSS3, and boilerplate frame works, I lost sight of the direction for this method. I hope you’ve found it useful.