What's the best way to organize CSS rules?

Question

What strategies help you keep track of a large number of CSS rules? How do you organize your files, your code blocks, and your rules?

Answer 1

Generally I try to put the rules from generic to specific. For example the beginning of the document might have rules for body, div, h1 ect. After that I'll move into class specific rules. Followed at the end for rules by id.

I've also seen people group rules together by their use. For example if your page has a table; you might group all your rules for styling the table, cells, data together. Possibly add some comments into the css file to explain what each section is for to make it easier to find later.

Answer 2

I found that selectors based on id or class is less fragile to changes and easier to maintain than the ones that I based position. Then we segment our rules into site (global), and application rules. Within each file we organize things alphabetically and from least to most specific (per css specification). We do not minimize or otherwise reduce readability of our rules, and comment them like it was code. When I refactor an HTML page the first thing I do is strip styling from the content, and move it into css files. I know this one is probably obvious.

/Allan

Answer 3

I use several techniques:

• Group by #ID / Class
• Comment major blocks, using an underscore for easy searching (/* IDName /)
• Using CSS shorthand helps keep the file size down, making it easier to manage.

There are a few good articles on the net that I've used. I'll try find them again.

Answer 4

For really big sections, it's also nice to break the sheet up into smaller logical chunks that each get their own sheet and link tag. That way, when you need to tweak some small part of the navbar styles to support the fancy new button most of the rest of your styles are sheets that haven't changes and are therefore still cached on your users machines.

Answer 5

I will normally break the main css file up into sections based on where on the page the rules appear - so there will be a section for the web page header, another for navigation bar(s), and so on.

I also break out a separate file for print media.

Like program files, I use comment blocks to indicate what rules are in the following section.

I don't believe there are significant performance advantages in having several small files as compared to a single large file though.

Answer 6

Separate layout rules from color and stylistic rules.

Answer 7

I like to store css in a Content folder that contains static content for a site. Then I usually try to have one css file per "business context". So if I had a website section where users registered for Trade Shows, the url may be "[host]/shows/" and my css file would be "[host]/content/styles/shows.css". If things get more complicated and "shows" gets too big then I might create a "content/shared/" folder and a "content/shows/" to match the subdomains of "shows". Renaming issues become trivial with Resharper or "Find & Replace".

Answer 8

My 4 tips:

Organize your css to indent child items further than the rest:

#main_side {
    width: 392px;
    padding: 0;
    float: right; }

    #main_side #featured_articles {
        background: #fff; }

    #main_side #frontpageads {
        background: #fff;
        margin: 8px 0; }

Use shorthands:

margin:5px 0 4px 10px;

Divide your stylesheet into specific sections:

Global Styles – (body, paragraphs, lists, etc), Header, Page Structure, Headings, Text Styles, Navigation, Forms, Comments, Extras

Optional: Use a compressor to squeeze your code into a smaller file size.

Answer 9

My basic approach is to look at it from a programmatic and a stylistic point of view.

• Avoid repetition
• Comment large blocks of code
• If possible use css shorthand properties
• Label classes sensibly, avoid things like class_001/tom_cruise that are meaningless

Order your CSS files like this:

• element declarations
• next global classes
• layout containers and sections.

Useful link: http://www.456bereastreet.com/archive/200610/useful_tips_for_writing_efficient_css/

Answer 10

I particularly appreciate the tips given in this article.

Answer 11

Broken into sections and subsections with a Table of Contents at the top. Alphabetized.

Answer 12

• I make a default file for some default rules(applied to most of sub-pages)
• Every sub-page has it's own .css stylesheet( if it's needed)
• I use shorthands (background: #FFF url(../images/header_1.jpg) 0 0 repeat-x;)
• Classes ony if I have more than one element with given class(if one element - use id)
• Avoid repetition, if you can inherit - do it

Answer 13

The most efficient use of CSS involves significant re-use of classes. While it's easy at times to group your classes and ID's based on where they appear on a page, this method quickly breaks down when you begin to appropriately re-use classes which end up appearing in multiple areas.

Additionally, you should avoid naming your css classes after their appearance, such as h1.blue or tr.55. Naming CSS classes in this way completely defeats the purpose of using CSS. Keep in mind that someday you might want to change everything that is blue, to red. If you name your classes .blue and .red, you have to touch the markup in order to accomplish your task. However, if you name your classes .moduleHeader or similar, you can change the colors of those moduleHeaders in the css file without ever touching the markup.

Well-built css files with significant re-use of classes is best organized alphabetically by class. This method will always be organized and will make sense to everyone who works on your project.

I prefer to organize my classes alphabetically in one large chunk and then have another chunk for my ID's organized alphabetically.

Depending on the size of the site, it can be a good idea to put structural elements into one file and 'stylistic' elements (colors, font choices etc) in another css file. This allows you to have a perfectly usable site with ONLY the structural elements, and it also allows you to "re-design" the site by only touching or swapping out the 'stylistic' css sheet.

In practice, I prefer to have one larger css sheet with both the 'pretty' things and the structure because it gets annoying to swap between the two in a production environment. However, depending on the structure of your team, it may work better for you in another arrangement.

Within one class or id declaration, I organize my attributes alphabetically as well. I've tried other organizational structures, but the only one that seems to work for other people, without training, is alphabetically.

Answer 14

for a large file of css rules I would organize it in this manner

1. provide any reset CSS rules first
2. provide any general/generic rules (eg p { color: #553423; } next
3. divide the remaining document by sections of the page
4. put each rule on one line with general rules followed by more specific rules
5. alphabetize selectors inside each rule

example:

/*****
/*  ~masthead
/*****

#masthead {background-color: #cc00ff; color: #fff; width: 950px; }
#masthead h1 { background: transparent url(logo.png) no-repeat; text-indent: -9000px; width: 200px; }

/*****
/*  ~content
/*****

#content { background-color: #fedefd; margin:0; width: 357px; }
#content h1 { font-size: 120%; font-weight: bold; margin: 50px 20px 50px 70px; }
#content p em { color: magenta; }

This way you can

1. easily search for a section (search for ~masthead and you're at the top of the section)
2. easily scan all the rules for a section at once to determine if something is covered or not
3. easily adjust rules even in long lines. alphabetizing selectors ensures that "color" doesn't appear twice in the same rule

Answer 15

Use CleverCSS, a small markup language which takes the pain out of writing and organizing CSS.

Answer 16

I keep all the styles appled directly to the tags at the very top of my stylesheet. Below that are any general CSS classes.

After that is the main structure, usually global. generally I find it easier to continually select by decedent for example:

#container { width: 600px; ... }
#container #header { .... }
#container #header h1 { font-size: massive; }

#container .column [ .. }
#container #left-column {.. }
#container #left-column #content { ... }

This has the benefit of providing a kind of indentation, and you can very easily see the structure of the page from within the CSS. Sometimes you will have to rename your style rule is the structure of the page changes, but it is not a big deal. This style works best when all your rules are on one line.

I change things up slightly when it comes to the content portion of my stylesheet, and just descend right off of my content div.

#content h2 { ... }
#content h3 { ... }
#content ol, 
#content ul, 
#content dl { ... }

Finally, I end off with style rules for particular pages. I have found that it makes the most sense to give the boy an ID based off of the filename or URI, and the body a class of the current directory of the file. This makes it very easy to target style rules in the main css to a particular page, or page group if needed. (obviously you should weigh that against including a new stylesheet.)

Inside of my style rule declarations, I keep all my rules well ordered, going from display attributes, position, size, margin, border, padding, background, color, text attributes, line attributes, word attributes to font-attributes. Conceptually going from the outside inwards (you could argue that font belongs above the text attributes. As long as you're consistent, that is all that matters).

I use shorthand for boxes (e.x. margin and border) because I have to TRouBLe remembering them (Top, Right, Bottom, Left). I avoid using shorthand for background and for fonts, because they are a little trickier to remember.

For example:

.rule { 
  display: block; visibility; visible; 
  position: relative; float: left; z-index: 1; top: 3px; left: 10em; 
  width: 100px; height 30px; overflow: hidden; 
  margin: 1px 3px 5px 1px; border:3px dotted #ff0; padding: 5px; 
  background-color: #f0f; background-image: url(/foo/bar); color: #000; 
  text-align: left; text-decoration: none; line-height: 3px; word-spacing: 2px; letter-spacing: 1px; 
  font-family: sans-serif; font-weight: bold; }

Answer 17

I agree with most of what has been posted here. I have also found that separating the design and the style ends up being more of a pain than a help, even though it sounds good in theory. I do like to separate my css into multiple files though. I generally have a main css for the major design elements of my site and then several smaller files, often in a hierarchy, as I need more specialized design elements. One issue with this is that it can become difficult to know which css file contains the style element I'm interested in, but I organize my projects with Aptana, which has search tools. Also, Firebug helps with this.

I have also found that I prefer keeping my css rules more-or-less self contained instead of separating them into smaller rules and then concatenating them in the class definition. I find it easier to maintain if all the code for a div, for example, is in one or two rules instead of many that I might have to go searching for. This may mean that there is some code repetition and a bigger css file, but the difference doesn't seem to be that large and I prefer the maintainability.

Answer 18

I stumbled upon this organizer via @smashmag on twitter, works better than I imagined - styleneat.com

I run my CSS through it once I'm done and ready to deliver, or when my stylesheet becomes too messy to handle.

Answer 19

Apart from all the tips mentioned by others, I tend to divide my CSS into multiple files. One file for the main navigation, one for the footer, one for main typography, one for forms, one for every distinct 'object' on the page.

I then create one general stylesheet that @imports all those files. When I'm ready to deploy to a production environment a tiny Ruby script expands those @import statements into a single file, thereby reducing the number of HTTP requests required.

In my experience this works a lot better than keeping it all in one file during development.

Also, I try to comment on my CSS rules as much as possible. I use multi-line comments for general description of the rule, and single line comments to explain single lines:

#some_object {
  /*
   * What, where, why, how...
   */
  font-size: 1.2em; /* 12px */
}

Finally, I cuse CSSEdit groups and indentation to combine related rules:

/* @group My section title */
    #some_rule {
        ...
    }
/* @end */

Answer 20

I have finally put down pen to the paper so to speak to jot down the method I follow and the reasoning behind it.

http://milanadamovsky.blogspot.com/2010/04/advanced-css-style-order.html

Milan Adamovsky

Answer 21

Try ProCSSor or Styleneat, both are great.

Answer 22

If you're splitting your CSS into separate files and you've got a lot of them, be aware that Internet Explorer has a limit of 31 CSS files. It won't load any styles beyond that limit.

Also, of course if you have a lot of files, you're creating extra work for your web server and increasing the number of connections, which will slow your page loads (again, especially in Explorer), so it's better to combine your CSS into a single monolithic file when you deploy your site, even if you have them separate during development.