Obsessive CSS Code Formatting: Patterns and Trends
Call me strange, but I format each of my CSS rules according to the following structure/pattern:
div#example element {
margin: 5px 15px 5px 0;
border: 1px solid #444;
line-height: 1.5em;
text-align: center;
background: #222;
font-size: 10px;
display: block;
padding: 5px;
color: #888;
float: left;
}
div#another div.example element {
border: 1px solid #444;
margin: 7px 0 17px 0;
letter-spacing: 1px;
font-weight: bold;
background: #222;
font-size: 1.1em;
cursor: pointer;
display: block;
padding: 3px;
width: 308px;
color: #888;
clear: left;
float: left;
}
div#another div.example element {
text-indent: -9999px;
overflow: hidden;
position: fixed;
display: block;
z-index: 9999;
padding: 0px;
margin: 0px;
bottom: 0px;
right: 0px;
}Notice how the right-hand edge of each block suggests a diagonal line? This is accomplished by placing the longest declaration at the top of the style block, then the second-longest, and so on until the shortest rule is finally placed at the bottom. I have been writing my CSS this way for several years now, and apply the principle to virtually all of my declaration blocks. Occasionally, other formatting patterns are seen. For example, layout divisions are frequently very similar in appearance due to similar rules with similar lengths:
div.subleft {
width: 400px;
float: left;
clear: none;
}
div.subright {
width: 377px;
float: right;
clear: none;
}
div.midleft {
width: 177px;
float: left;
clear: none;
}
div.midright {
width: 200px;
float: right;
clear: none;
}Technically, I am still listing the rules in descending order according to length, but the similarity of the rule blocks presents a uniform aesthetic demonstrating clear thought and solid design. Further, the overall pattern consisting of short, uniformly sized blocks is easily recognizable as related to positioning and layout. Over time, familiarity with the different patterns facilitates efficient CSS navigation. Further, the highly elaborate, systematic ordering of CSS rules conveys a sense of completeness and closure to finished files. Also, as the degree of organization closely correlates with overall processing time, determining inherent code quality is greatly facilitated while scanning through previously designed stylesheets.
28 responses to “Obsessive CSS Code Formatting: Patterns and Trends”
Dude, you’re right, that is totally obsessive. I bet it makes for a very easy on the eyes css file though. I’ll have to dig through mine and see if I notice any patterns.
Yes, it is.. Or at least, it sure seemed that way several years ago when I felt compelled to begin practicing it. These days, writing CSS code this way seems almost second nature — I don’t even think about it!
I’d agree that this is a bit obsessive. ;) I have various OCD-like behaviours (never been officially diagnosed so I won’t call myself OCD), but with CSS formatting I practise a very simple, logical method: alphabetical ordering!
By arranging your rules alphabetically, you always know roughly in what part of the order your rule will be. The rule also won’t change position depending on the value, while with your system I imagine you’d have to re-order the rule if you changed, say, a margin: 1px; to a margin: 1px 1px 1px 0;.
You can see where I used my system here:
http://www.bramleycarrington.co.uk/css/stylesheet.css
From a totally biased perspective I’d say my technique is more useful (especially when sharing code with colleagues), while yours is pretty much completely for aesthetics. Still, everyone does things their own way. :)
Yes, that is one of the great things about CSS — it is so customizable that everybody can write it their own way. For me, the visual appearance of code (CSS, XHTML, PHP, etc.) on the page is immensely important. If the source code doesn’t look clean, well-structured, and highly scrutinized, then I usually either take the time to do it myself or refuse to use it at all. There is something very inspiring to me about well-formatted source code, CSS and otherwise. I think it’s great that people are getting into alphabetizing their code — it may in fact be far more useful, but it just doesn’t look as well-organized and logically written (to my obsessive eyes).
I guess I’m in the minority – I try to group my css logically. For example, I put all the base elements in one section, all elements with ID’s in a another section, and classes in another section. Within each section, I have subsections that grouped together based on the part(s) of the page(s) they are styling. For example, all of my left nav classes will be grouped together, etc. I really don’t mind what it ends up looking like. I’m a big fan of ‘ctrl+f’, that’ll take me to my destination much faster than any aesthetic organization. I do keep things clean in all my code (css or otherwise) by following strict indenting patterns and so forth because it helps me to know where I am in my code.
Hey, no disagreements here about such meta-organizational techniques. Keeping the selector blocks themselves well-organized and logically presented is an entirely different topic. Here, we are focusing in on CSS patterns and trends for code presentation within individual selector blocks. Even at this level, there are many different formatting techniques for code presentation, including my admittedly obsessive diagonal system, Ryan’s somewhat retentive alphabetical model, and many others as well. I guess the point is to actually have a system that works best for you, regardless of your preferred level of organizational focus, whether selectors, properties, values, declaration blocks, or whatever!
Before I came here, I thought my code formatting habits were OCD, but now I see I’m just a pretender – bravo!
I follow a simple system. The first set of declarations establish the typography of the site, and deal with general text formatting. Next, each major section of the page (the header, main content, navigation, forms etc.) is clearly separated by whitespace, with selectors appearing in roughly the same order that the elements they correspond to will appear in the markup. Finally, I obsessively alphabetise and minimise each property declaration.
Oh, yes: I always put rules with only one property on a single line, i.e. “
#some-ID { margin: 0; }”. It just looks right to me!Another alphabetizer! I guess it’s more popular than I had first imagined, although, unless your selector blocks are like 50 lines thick, how useful is it really to alphabetize the declaration blocks? It seems like it would be just as easy to quickly scan the five or ten lines to find the target property rather than reading through the list alphabetically. On the other hand, alphabetizing declarations is solid, consistent method of keeping your code organized and consistent — and that is the whole point of this thread. As for minimizing CSS properties — I completely agree that it is good practice to do so. And for the single-property selector blocks, I have embraced that practice as well, as I find it helps bring a certain aesthetic texture to surrounding code blocks. By breaking up the repetition of typical selector blocks with a few well-placed one-liners, it is possible to bring additional character to a series of rules, almost like the role punctuation plays within a paragraph of text.
The useful thing about alphabetising – especially in large blocks, as you observed – is that you can very quickly verify whether or not a certain property has already been set. However, it probably has more to do with the perverse pleasure I derive from knowing that everything is in order!
I agree about the texture that one-liners bring; they break up the flow nicely, and it makes them feel more like brief asides, or perhaps the delicate touch of a master craftsman. (Pretentious, much?)
Of course, when it comes to clarity and grace, comments and whitespace are the peerless companions of any good CSS author. Any opinions on the age-old jihad concerning tabs vs. spaces?
Ah yes, I see now how alphabetized declarations could assist in determining the presence (or absence) of a specific property/value pair. I will agree now that, technically, alphabetization is a more consistent and rigorous technique for ordering the contents of selector blocks. Still, I can’t quite get past the difference in appearance between any given alphabetized code block and one that has been organized specifically for presentational/aesthetic purposes. Call me a total CSS snob, but if the code doesn’t line up or demonstrate some form of clear pattern, it just looks unfinished and terribly sloppy! I love your second point and agree that we probably sound a bit pretentious discussing such minutia so relentlessly, but it’s difficult not to share the satisfaction of a well-placed, single-line selector block. As for the old “tabs-vs-spaces” jihad, it’s so over it hurts: (single) tabs all the way! ;)
aaaarrrrggghhhh!
It would drive me crazy to have to edit css like this! You’d never know ahead of time where to expect something.
I’d say, if in doubt: alphabetize.
Personally (and my approach would probably drive others just as mad!) I try to arrange properties based on how they affect the box model and document flow. Flawed at best, but I know that I’ll always have dimensions (height/width) near the top, and things like color and background at the bottom.
I’m not suggesting anyone follow my lead as it is pretty subjective guess-work. But I don’t think formatting based on the character width of the property/value makes sense or good practice. I’d advise alphabetical order to anyone just getting into css. (although I personally prefer to see ‘position’, ‘top’, ‘left’, ‘right’, ‘bottom’ etc paired together as it makes logical sense in my mind – so it’s always been hard for me to switch to alphabetical)
I don’t mean to be critical. My method is probably just as hard to follow as yours. And I’m glad you got this conversation started. It’s interesting to see how other people approach this thing with no clear guideline.
@Perishable – Ryan Williams (comment #3) made a good point with his “margin: 1px; to a margin: 1px 1px 1px 0;.” example.
As I mentioned, I wouldn’t recommend my approach (order loosely and subjectively based on affect to box model), but I can generally and fairly reliably expect certain properties to be at the top or the bottom of any given declaration.
I also try to keep my css lean and mean, but sometimes you do end up with 13 properties as with your example “div#another div.example element”
It just doesn’t feel right (to me) to put arbitrary and transient formatting ahead of any form of logical or standardized structure be it box model, alphabet, or what have you.
Again, I’d recommend going the alphabet route for anyone wondering what to do. I keep thinking that someday I might finally switch to alphabetizing but I just can’t bring myself to do it. although it would be more in sync with FireBug which is *almost* reason enough.
I have to admit though, your approach is easy on the eyes