views:

1140

answers:

6

Has there been any attempt and creating a formalized method for organizing CSS code? Before I go and make up my own strategy for keeping things readable, I'm wondering what else is out there. Goggle hasn't been very helpful, as I'm not entirely sure what terms to search for.

I'm thinking more along the lines of indenting/spacing, when to use new lines, naming conventions, etc.

Any ideas?

A: 

Well I don't personally know of any convention per se, but I know there are a lot of recommendations out there that are really good idea to follow, but basically depends in how you want to implement your CSS for you to choose the one that fits you the most.

Luis Armando
+7  A: 

Natalie Down of ClearLeft fame produced a really great slide show covering this topic and more http://natbat.net/2008/Sep/28/css-systems/

Download the PDF as it includes a lot more information than the slide show. I'd recommend this to CSS devs of all skill levels.

Andy Ford
I like it. Natalie essentially laid out what I've been trying to accomplish for years. The big problem is getting coworkers to go along with it...
Ryan Kinal
+3  A: 

This is all very subjective as per the usual code formatting debates and I do not know of any formalized conventions.

The method I've chosen is to use all lowercase classes and ids with underscores separating words (#page_container for example). I declare all my tag styles first (html, body, ul, etc.), then all classes and ids, sorted alphabetically. Additionally, all the styles defined in each class, id, or tag are defined alphabetically as well. Using this convention makes it easier to track down a particular style.

For formatting, I always compress it as small as possible, but still legible. I put everything on one line with appropriate white space. If you have Visual Studio, you can specify this format and have it automatically formatted this way for you (Set Style to Compact rules under Tools, Options, Text Editor, CSS, Format).

Naming conventions are extremely subjective here, but the thing to keep in mind is to name your elements as their intended purpose, not their styled meaning. For example, if you have a company slogan you want to style in a large, red font name the id #slogan instead of #red_bold.

Here's a full example to give you an idea:

body { background-color: #fff; color: #999; font-family: verdana, arial, helvetica, sans-serif; font-size: 76%; padding: 0; margin: 0; }
a { color: #2c5eb4; text-decoration: none; }
a:hover { text-decoration: underline; }
h1, h2, h3, h4, h5, h6 { color: #f70; font-family: helvetica, verdana, arial, serif; font-weight: bold; margin: 1.2em 0; }
h1 { font-size: 2.4em; line-height: 1.2em;  margin-bottom: 0em; margin-top: 0em; }
h2 { font-size: 1.7em; }
h3 { font-size: 1.4em; }
h4 { font-size: 1.2em; font-weight: bold; }
h5 { font-size: 1.0em; font-weight: bold; }
h6 { font-size: 0.8em; font-weight: bold; }
img { border: 0; }
li, ol, ul { font-size: 1.0em; line-height: 1.8em; list-style-position: inside; margin-bottom: 0.1em; margin-left: 0; margin-top: 0.2em; }
#content { clear: both; margin: 0; margin-top: -4em; }
#columns { height: 36em; }
#column1, #column2, #column3, #column4 { border-right: 1px solid #dbdbdb; float: left; width: 18%; margin: 0 0.5em; padding: 0 1em; height: 100%; }
#column1 { width: 28%; }
#column1 input { float: right; }
#column1 label { color: #999; float: left; }
#column2 a, #column3 a { font-weight: bold; }
#column4 { border-right: 0; }
#form { margin: 0 2em; }
.help_button { float: right; text-align: right; width: 30px; }
cowgod
Not to insult your coding style — it works for you, which is the main thing — but I’ve always hated the all-on-one-line style. I find it really unreadable. There’s a convention in programming that one line of code should do one thing, to make things readable. What’s the thinking behind the all-on-one-line style?
Paul D. Waite
@Paul D. Waite Having the styles all on one line makes for a smaller file size but still legible enough to work on when necessary. Ideally, you would have some build process that compresses it even further on production, but this method is a good equilibrium between the two methods (totally compressed versus one style property per line).
cowgod
Man oh man, yes, build process. Computers are there so that humans do less work, not more. YUI Compressor makes your non-gzipped files as small as possible, and gzip compression (which your server is probably doing already) is, on its own, 3 or 4 times more effective that YUI Compressor anyway. Making your code less readable is not the right way to reduce the size of files delivered to the end user.
Paul D. Waite
+2  A: 

Here's a draft of how I order my css properties. It roughly follows the guideline of doing positioning and layout first, then typography, then backgrounds and other minor things. I try to order my properties by how they affect the box model as much as is reasonably possible. However, my ordering tends to shift around a bit. I'd appreciate any comments on this.

el {
 display:;
 float:;
 clear:;
 visibility:;
 position:;
 top:;
 right:;
 bottom:;
 left:;
 z-index:;
 width:;
 min-width:;
 height:;
 min-height:;
 overflow:;
 margin:;
 padding:;
 border:;
 border-top:;
 border-right:;
 border-bottom:;
 border-left:;
 border-width:;
 border-top-width:;
 border-right-width:;
 border-bottom-width:;
 border-left-width:;
 border-color:;
 border-top-color:;
 border-right-color:;
 border-bottom-color:;
 border-left-color:;
 border-style:;
 border-top-style:;
 border-right-style:;
 border-bottom-style:;
 border-left-style:;
 border-collapse:;
 border-spacing:;
 outline:;
 list-style:;
 font:;
 font-family:;
 font-size:;
 line-height:;
 font-weight:;
 text-align:;
 text-indent:;
 text-transform:;
 text-decoration:;
 white-space:;
 vertical-align:;
 color:;
 opacity:;
 background:;
 background-color:;
 background-image:;
 background-position:;
 background-repeat:;
 cursor:;
 }

Personally I prefer to keep one property per line indented one tab, with the closing curly brace indented one tab. To me it's more legible this way, but that's definitely a matter of opinion/preference.

I used to tab indent css declarations to match my html parent/child relationships as much as possible, but I no longer do that. The grouping feature ofCSSEdit helps greatly reduce the temptation to do so.

CSS doesn't really have any prescribed convention for code structure. So it comes down to what works best for you.

Andy Ford
I pretty much use that ordering too, although I put `background-color` and `color` next to each other, and I put them just after padding. It’s funny the habits you can get into. I have heard that keeping a consistent order throughout a stylesheet can help gzip compression, which looks for repeated strings. If you’ve got the same styles used in different places, keep the order the same means they’ll compress better with gzip.
Paul D. Waite
A: 

We had some good discussion here.

Nathan Long
A: 

Files should be modularized, so you can make use of @imports. I typically have a base.css file for base classes (such as typography and colors). Depending on your site structure, it may be advantageous to also have other CSS "partials" to reuse throughout user-facing stylesheets. These descendant stylesheets can extend base styles with more granularity as needed (E.g., .warn {color:red;} might get extended by p.warn {font-style:italic;}, or h1.warn {border:5px solid red;}), which is a great design pattern for implementing so-called object-oriented CSS.

Within the files themselves, I like to alphabetize my selectors and property lists. I have tried maintaining separate lists for different types of selectors (an id list first, then my list of classes, and then my list of element selectors), but I've found this unnecessarily difficult, so I have all selectors in the same alphabetical list. That way I can quickly find the root of all complex selectors or any styles given to a simple selector.

Within complex selectors, I list each selector alphabetically.

If I can't use Sass for some reason, I might imitate its nesting pattern (I'm still unsure if this is working out or not), like so:

@import url('/css/base.css');

a {
  color:#369;
  font-family: Helvetica, sans-serif;
  font-weight: bold;
  text-decoration: underscore; }
  a img {
    border: 0; }

blockquote, .nav, p {
  margin-bottom: 10px; }
blockquote {
  background: #eee;
  padding: 10px; }

h1, h2, h3, h4 {
  font-family: Georgia, serif; }
h1.warning {
  border: 5px solid red; }

.nav a {
  font-size: 150%;
  padding: 10px; }
.nav li {
  display: inline-block; }

p.warning {
  font-style: italic; }
  p.warning a {
    background: #fff;
    border-bottom: 2px solid #000;
    padding: 5px; }
  p.warning .keyword {
    text-decoration: underline; }

Unfortunately, you may look for the margin for p and not realize that it's part of the blockquote, .nav, p. This also isn't very "object-oriented" design, but it's arguably better than putting strings of classes on virtually every element that requires styling.

So, this approach isn't perfect and doesn't completely free you from sometimes having to find-in-file, but it's the best approach I have developed when I cannot use CSS templating tools for reasons beyond my control. I would love to hear any suggestions on improving this method :)

David Rivers