Ask HN: Anyone have a really smart way to organize css?

After many years doing CSS my best workflow has come to this:

    reset.css //for resetting browsers
    grid.css //if I'm using a css framework
    global.css //styles that are shared across the site
    section.css //styles that pertain a specific section. The name of the file varies, i.e. "about.css".

You need a good code editor that allows you to open files without tabbing or reaching for the mouse, I use Textmate's Command T to switch fast among my files.

reset.css There's a bunch around, I use the one from htmlboilerplate.com, but there's many good ones available. (Eric Meyer's). You will almost never touch this file.

grid.css I only use this occasionally, when I'm working on sites where the grid is very clear and I take out all the stuff I'm not going to use. I usually go for a three col version of 960.gs and trim it to about 12 lines of css. Never touch this.

global.css Here you put your nav, your footer, you body styles, etc. I think that separating by colors and typography doesn't make sense, because you usually change a widget's appearance.

section.css I count on the body tag having a classname, so I can have body class="about" and then do...

    .about section.photo {...}

This way you never override your styles accidentally.

Miscellaneous I avoid the one declaration per line convention when I have similar styles and I want to be able to read them in a table format, i.e.

    .available {background-color: #0f0;}
    .taken     {background-color: #00f;}
    .deleted   {background-color: #f00;}

I usually start from the most generic to the more specific, but I don't worry too much about code order because in the end I just do a search and reach it in no time.

A good example of some super organized CSS is in the HTML5 Boilerplate by Paul Irish. Found here: https://github.com/paulirish/html5-boilerplate/blob/master/c... I sometimes use multiple instances of the same selector, especially if a project starts getting very big. I like to separate each function of the site into it's own block after the footer declarations. It lets me stay organized during development and ensures that I can keep track of what I'm working on while I'm working on it. Here's the order I'm currently using, which was inspired by the above:

    /* HTML STRUCTURE STYLES */
    body { foo: bar; }
    h1 { foo: bar; }
    a { foo: bar; }
    /* Image Replacement & Hacks */
    .ir { foo: bar; }
    /* Container Styles */
    #header { foo: bar; }
    #main { foo: bar; }
    #footer { foo: bar; }
    .column { foo: bar; }
    .sidebar { foo: bar; }
    .img-cotainer { foo: bar; }
    /* Everything inside of #header */
    .navigation { foo: bar; }
    #header li.nav { foo: bar; }
    /* Everything inside of #main */
    .content { foo: bar; }
    /* Everything inside of #footer */
    .social { foo: bar; }
    #footer li.nav { foo: bar; }
    /* Everything in specific view inside of a container from above */
    .profile { foo: bar; }
    .comments { foo: bar; }
    /* Media Queries */
    @media all and (orientation:portrait {
      * { foo: bar; }
    }
    /* Print Styles using Media Query */
    @media print {
      * { foo: bar; }
    }

On an MVC site, I organize by controller. There's one general file for generic cross-site stuff (header/footer, etc.), supplemented by another CSS file that shares the markup for all controller-specific pages.

This gives a max of two css files per page. For the landing page I compress the generic file along with the controller-specific css file for the default page into a single file. This speeds up the loading process while preventing too much bloat. Since the other pages are usually hit after the landing page they require only a single extra download. Any reset code can be included in there as well, although maintained as a separate file.

I doubt this approach is ideal when it comes to organizing things, but it's fairly fast when it comes to development. I design by including css in style="" and then refactoring the markup into classes once the design is complete. Saves a lot of back and forth while getting things lined up.

Start by using sass reset.sass 960gs.sass default.sass In default @include reset and 960gs (sass compiles it all into one css file)

Then use a per page sass file that references default.sass

If you want something pre-built that does all this use compass.

The problem with absolutely unique elements is that, in a complex enough website (that evolves over time), they often end up not being unique after all.

I agree about IDs for JavaScript though.